preventing bitcast in generated code

Clang Frontend
1

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

2

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

3

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

4

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

-Chris

5

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

6

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

-Chris