Modify ConstantExpression to store these flags and then use them.
Update of test per flags rename and correction of one condition (need to ignore non-floating-point types).
(mark unaccepted waiting to settle the ConstantExpr case)
I thought that since it was float specific it couldn't be added, but I just checked and saw that we have integer nsw/nuw already on ConstantExpr, so it seems possible.
ConstantExprKeyType accepts unsigned short SubclassOptionalData. FastMathFlags are currently unsigned Flags but there is not reason they couldn't be uint16_t instead right?
David: do you know why we don't already have FastMath on ConstantExpr? Is it because there was no case with FP where we wouldn't constant fold immediately?
Now, what are the potential benefit to deal with Floating point ConstantExpr with FastMath flags? And what are the complications (i.e. will we have to add extra care everywhere we deal with FP ConstantExpr?)?
AFAIK, yes. We didn't believe the flags would meaningfully change the result of what expression we'd give back. This would change with the new flags.
Talk with David on IRC, I agree with him that it seems cleaner to have this.
I forgot about this change and another code related to constant expressions got removed from different patch, so I thought there is no need to do something about them.
I can try if it's just adding the field and considering it in several places where folding is performed. If it's significantly more complex, then I'm afraid someone else should do this as I'll stop contributing to LLVM very soon (and either upload the rest of the patches for ARM and FENV pragma in Clang or pass them over to somebody else to do this).
By the way, the field is not of unsigned short type:
Replacing with FastMathFlags for ConstantExpr, separate patch would almost completely undo this one and two more (two following ones, which are related to Strict flag), so I guess it's better to have it here.
Realized that I forgot to update other methods of ConstantExprKeyType to include the new field, will do that later, it won't change much. Optional data field was already used and it's only 7bits in Value class, which would need to be extended to hold new flags, so I added a field to ConstantExpr instead.
In case of binary expressions SubclassData holds 0 and SubclassOptionalData holds binary operation specific flags. We can use SubclassData, which will be inconsistent with other types of constant expressions, but can be done if that's OK.
No, it wasn't. FMF can be from instruction which contains CE as one of its operands, the argument was added for llvm::ConstantFoldInstruction.
No, I just didn't see such use and thought maybe there is a reason for that, which isn't documented. I'll change this then.
Again, now that constant expression have dedicated FMF, I'm not sure why we should apply the parent instruction FMF?
It is very possible that I miss something, David and/or Hal may have an opinion on this?
Maybe we can drop it, I'll need to check (don't remember by now) and see whether it causes any problems. Initially it did make sense to propagate flags of instruction to its operands, I agree that it might be useless now.