subtle issue with soft-float and new attribute scheme (possibly an issue with other attributes)

Project Infrastructure LLVM Dev List Archives
1

I can't say this is a bug it is changed behavior from before the new attribute scheme.

This issue may appear with other attributes. (there are other attributes that clang will now place
on each function)

If you run clang as a single pass to create a .ll and don't say -msoft-float, it puts the attribute use-soft-float=false on every function. (It used to be that in that case -msoft-float had no effect because those
attributes where not preserved in the IL. )

Then if you run llc and say -soft-float, what happens is that the code generator will compile everything as soft-float, but the value of the following will be false in XXXISelLowering getTargetMachine().Options.UseSoftFloat

When the constructor for XXXISelLowering is called, TM.Options.UseSoftFloat will be true.

What is interesting is that code for "make check" won't have any of the new attributes there so
it will work as before.

I was seeing this behavior and could not figure out how my tests could possibly pass if getTargetMachine().Options.UseSoftFloat was returning the wrong result.

2

Just to clarify...

The target independent part of the code generator knows from the command line to use soft float when it legalizes.

However, any other code (target independent or dependent) which later tries to find out if soft float is in effect is going to get the wrong answer.

3

My understanding is that with the new attribute system we should
deprecate and eventually remove the codegen command line options.

4

My understanding is that with the new attribute system we should
deprecate and eventually remove the codegen command line options.

How is that possible?

5

Because all the information will be available in the attributes. If,
for example, codegen can decide on hard float or soft float for a
function based on an attribute, clang can set it and the default when
the attribute is not present is mostly arbitrary (mostly because of
backwards compatibility considerations).

Cheers,
Rafael