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? We may need something akin to a fence over which no code motion can occur. Some compilers use special operations to represent parentheses for Fortran codes. I don't think that will work very well for LLVM, however. I think the proposal is heading in the right direction. We just need to fill in the details. -Dave
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
On Wednesday 03 March 2010 15:11:48 Török Edwin wrote:> > 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?> 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)That's sort of along the lines of what I was thinking. I was just trying to list the questions that immediately came to mind, not looking for solutions just yet. :)> > 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 ;)Signalling NaN is one case. I'm sure there are others.> > 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.I agree. -Dave