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