[LLVMdev] folding x * 0 = 0

[Török Edwin]

On 03/03/2010 10:36 PM, David Greene wrote:
> On Wednesday 03 March 2010 13:13:50 Chris Lattner wrote:
>>> Why not at first create a compile time option for this so that the
>>> code is already available for special purposes?
>> I'm not sure how that would work, but it most likely wouldn't fit with the
>> design of llvm.  If this is important, I'd rather fix the representational
>> issue.
> 
> I agree.  The option should control the kind of IR generated as Chris outlined 
> in the document.
> 
> We need to figure out exactly what "strict" means.  Is it like "restrict" in C 
> where it only has meaning with respect to other things marked "restrict"
> or is it more general?  Can I reassociate a strict with a relaxed?  Is it
> possible that "strict" will mean different things for different operations?

I think the strict flag should determine the mathematical properties of
the operation itself, i.e. give it all the properties that integer
operations have (associativity, and whatever else is missing).

You then have to write down what mathematical properties you need for
your optimizing transformation, and if ALL operations involved in it
fulfill the properties you can do the xform.
You can have strict and relaxed operations in same functions, and
optimize (even the FP values that would eventually be used in a strict
OP), if the operations involved in the optimization step has all the
needed mathematical properties.

You shouldn't realistically have both relaxed and strict ops in the same
function, but it can happen with inlining.

Lets note associative adds with a+, and strict ones with s+.

For associativity for example you need 2 operations to be associative:
(X a+ Y) a+ Z -> you can transform this to X a+ (Y a+ Z)

(X s+ Y) a+ Z -> you can't transform this

((X s+ Y) a+ X) a+ Y, you can partially transform it,
 1) lets note X s+ Y = Z
 2) (Z a+ X) a+ Y -> Z a+ (X a+ Y) -> (X s+ Y) a+ (X a+ Y)
 3) you can always choose to restrict a relaxed op (a+ -> s+)
    (X s+ Y) a+ (X s+ Y) -> 2 a* (X s+ Y)


> 
> We may need something akin to a fence over which no code motion can
> occur.

Maybe for signaling NaN, I don't know how those things work.
I tend to avoid using any FP code in my code ;)

> 
> Some compilers use special operations to represent parentheses for Fortran 
> codes.  I don't think that will work very well for LLVM, however.

With strict/relaxed flags for each operation (not value!) I think it can
work, IF the frontend sets the flags appropriately.

Best regards,
--Edwin