[LLVMdev] optimization in presence of floating point

[Reed Kotler]

For reordering issues, it would be useful for llvm ir to provide various 
ways to control reordering.

for example, a wrapper that indicates that other operations cannot be 
moved inside the wrapper.

or a wrapper that indicates that the IR in it must be processed canonically.


I think GCC may already have some of this but I'm not sure.


On 04/17/2013 08:59 PM, Hal Finkel wrote:
> ----- Original Message -----
>> From: "reed kotler" <rkotler at mips.com>
>> To: LLVMdev at cs.uiuc.edu
>> Sent: Wednesday, April 17, 2013 8:32:23 PM
>> Subject: [LLVMdev] optimization in presence of floating point
>>
>> an interesting problem occurs if you do interval arithmetic.
>>
>> void foo() {
>> float XL, XU, Y, Z;
>>
>> ....
>> call_change_rounding_mode(lower);
>> XL = Y + Z; // lower bound
>> call_change_rounding_mode(upper);
>> XU = Y + Z;
>>
>> }
>>
>> Two issues here:
>> 1) will the compiler mistakenly treat Y+Z as a common subexpression.
>> 2) might it move the call_change_rounding_mode after the assignment
>> to
>> XU since it seens no dependency.
>
> I have come across these issues myself as well. To be fair, Clang does not support the FENV_ACCESS pragma, and as I recall, the standard allows an implementation-defined default value (which, in our case, cannot be changed). Moreover, LLVM internally does not have an option to enable the correct conservative side-effect model to make all of this really work correctly.
>
>   -Hal
>
>>
>> This is actually to my previous mips16 ir post but is a question of
>> more
>> wide interest.
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>