[LLVMdev] Is shortening a load a bug?

Bagel bagel99 at gmail.com
Fri Sep 12 15:33:22 PDT 2014


On 09/12/2014 11:14 AM, Quentin Colombet wrote:
> 
> On Sep 11, 2014, at 9:10 PM, Reid Kleckner <rnk at google.com
> <mailto:rnk at google.com>> wrote:
> 
>> On Thu, Sep 11, 2014 at 5:17 PM, bagel <bagel99 at gmail.com
>> <mailto:bagel99 at gmail.com>> wrote:
>>
>>     The phrase "As long as loading an i8 is legal" is the whole point.  What
>>     if it isn't?  How do I specify that (should of specifying the load as
>>     volatile, which is overkill)?  As an author of a front end, I want to
>>     know what the contract is when I say load 32-bits?  When I say load
>>     32-bits I mean load 32-bits.
>>
>>     I think it's a bug because there is no good way do avoid it and it breaks
>>     device drivers.
>>
>>
>> This sounds like the *exact* use case for volatile, where the load is
>> observable in some way other than the result that it is used for. If i8 is a
>> legal type for the rest of your ISA, then this should be a volatile load. 
> 
> I agree with Reid.
> You should use volatile. Loading a i8 is legal in the ISA.
> 
> -Quentin

This is an "if all you have is a hammer, everything looks like a nail"
approach.  "load volatile" causes several things to happen:
1. The load size is not changed.
2. The loaded value is not "cached" in a register, i.e., the load can
   never elided.  Several loads may be issued even though the value
   of the object does not change.
3. The load may not be moved around another "load volatile" of a different
   object.

All I want is the first thing.  Things 2 and 3 are orthogonal and just cause
worse code to be generated.  Just because C got this wrong is no reason to
perpetuate history.


Is there a flag that disables this "load narrowing" optimization?

brian




More information about the llvm-dev mailing list