preventing bitcast in generated code

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

preventing bitcast in generated code

Jochen Wilhelmy
Hi!

I compile a subset of c++ to llvm IR that is then executed by a
kind of virtual machine that is not capable of executing all instructions.
For example if I have a struct with two floats and copy it form
one location to another clang uses a bitcast to i64 to copy it
(x86 target).
Can I implement an own TargetInfo to prevent this?
Of course I need an own TargetInfo to describe my virtual machine
anyway, but the question is how I prevent the generation of
bitcast ops.

-Jochen

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: preventing bitcast in generated code

Chris Lattner

On May 10, 2010, at 10:30 AM, Jochen Wilhelmy wrote:

> Hi!
>
> I compile a subset of c++ to llvm IR that is then executed by a
> kind of virtual machine that is not capable of executing all instructions.
> For example if I have a struct with two floats and copy it form
> one location to another clang uses a bitcast to i64 to copy it
> (x86 target).

You will never be capable of eliminating all bitcasts, but...

> Can I implement an own TargetInfo to prevent this?

Yes, in this case it sounds like it is being generated from the X86-specific ABI handling code.  Implementing your own TargetInfo for ABI lowering will allow you to avoid this specific bitcast.

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: preventing bitcast in generated code

Jochen Wilhelmy
Hi!

Now I have implemented my TargetInfo which derives from clang::TargetInfo
to define type widths and alignment, but there is no ABI lowering.
clang still generates (in unoptimized code) a llvm.memcpy.p0i8.p0i8.i32
to copy my struct. Is this hard coded or are there other classes I have
to override?

By the way in TargetInfo.h there are lines like
unsigned getBoolWidth(bool isWide = false) const { return 8; }  // FIXME
unsigned getBoolAlign(bool isWide = false) const { return 8; }  // FIXME

Later on I'd like to define bool as 1 bit, therefore would it be
possible to fix this?

-Jochen

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: preventing bitcast in generated code

Chris Lattner

On May 10, 2010, at 1:29 PM, Jochen Wilhelmy wrote:

> Hi!
>
> Now I have implemented my TargetInfo which derives from clang::TargetInfo
> to define type widths and alignment, but there is no ABI lowering.
> clang still generates (in unoptimized code) a llvm.memcpy.p0i8.p0i8.i32
> to copy my struct. Is this hard coded or are there other classes I have
> to override?
>
> By the way in TargetInfo.h there are lines like
> unsigned getBoolWidth(bool isWide = false) const { return 8; }  // FIXME
> unsigned getBoolAlign(bool isWide = false) const { return 8; }  // FIXME
>
> Later on I'd like to define bool as 1 bit, therefore would it be possible to fix this?

No.  These are memory sizes.  Memory is always in units of bytes.

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: preventing bitcast in generated code

Jochen Wilhelmy

> No.  These are memory sizes.  Memory is always in units of bytes.
>    

Ok, having getBoolWidth and getBoolAlign 8 matches the
"i1:8:8" part of the description string. But is it possible that i1
instead of i8 is used
for the bool type? According to "i1:8:8" this still should be one byte
but the difference
is that the resulting code doesn't need to care about bit 1 to 7.

-Jochen

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: preventing bitcast in generated code

Chris Lattner

On May 11, 2010, at 2:21 AM, Jochen Wilhelmy wrote:

>
>> No.  These are memory sizes.  Memory is always in units of bytes.
>>  
>
> Ok, having getBoolWidth and getBoolAlign 8 matches the
> "i1:8:8" part of the description string. But is it possible that i1 instead of i8 is used
> for the bool type? According to "i1:8:8" this still should be one byte but the difference
> is that the resulting code doesn't need to care about bit 1 to 7.

I don't think so, but try it out and see?

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev