[PATCH] propagate IR-level fast-math-flags to DAG nodes, disabled by default

[escha]

The “unsafe FP math” transforms aren’t enough; the problem is that even the *safe-math* transforms need to propagate flags from their source nodes, or you end up with un-CSEable duplicates (and of course, lose flags for future transformations!). You need to pass flags in for *every single creation of an FADD, FSUB, FADD, or FDIV*, as far as I can tell. This involves a huge amount of diffs that look like this:

     // fold (fneg (fsub A, B)) -> (fsub B, A)
     return DAG.getNode(ISD::FSUB, SDLoc(Op), Op.getValueType(),
-                       Op.getOperand(1), Op.getOperand(0));
+                       Op.getOperand(1), Op.getOperand(0),
+                       &cast<BinaryWithFlagsSDNode>(Op)->Flags);

One idea I had was to allow conservative CSE. That is, allow CSEing nodes with fast-math flags, even if their flags differ — just, when CSEing them, pick the intersection of the two flags. This will guarantee that CSE will still function, even if DAG folds don’t properly maintain fast-math flags. But we still need to eventually add all these flag propagations; otherwise having fast-math flags in the DAG is useless at best, isn’t it?

—escha



> On Aug 4, 2015, at 7:26 AM, Sanjay Patel <spatel at rotateright.com> wrote:
> 
> Does anyone see a workaround to do this piecemeal with FMF enabled?
> 
> Otherwise, I see about 30 checks for UnsafeFPMath transforms in DAGCombiner...so I could revert r243687, start working on the combiner fixes, and then turn the flag back on when DAGCombiner is FMF-clean.
> 
> But this wouldn't be perfect if you have more UnsafeFPMath transforms in your backend. You'd have to patch those too before we turn the flag back on.
> 
> Any other ideas about how to proceed?
> 
> On Mon, Aug 3, 2015 at 4:52 PM, escha <escha at apple.com <mailto:escha at apple.com>> wrote:
> We’re getting significant CSE regressions on our backend, caused by the fact that none of the DAG folds propagate fast-math flags. This results in nodes not being CSE’d, since we only CSE nodes if they have identical flags (and thus worse codegen).
> 
> I was able to get rid of many of them by adding flag propagation to FNEG folding, but there’s way more than just that.
> 
> —escha
> 
>> On Jul 29, 2015, at 11:51 AM, Sanjay Patel <spatel at rotateright.com <mailto:spatel at rotateright.com>> wrote:
>> 
>> For reference, fixes for PR24141 are in:
>> http://reviews.llvm.org/rL243293 <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL243293&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=EH36SVVrOANvPpWUfmtjHvcZene16JZYtYcOsOWHmmQ&s=oJkUxyP-U28dL9zPjcyCjESFgqf9fEa1WxScYHC1BLE&e=>
>> http://reviews.llvm.org/rL243498 <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL243498&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=EH36SVVrOANvPpWUfmtjHvcZene16JZYtYcOsOWHmmQ&s=9UShb3DxctMQors5uP4ErkfZ2ETsaqYXEeRLX8qKYt0&e=>
>> http://reviews.llvm.org/rL243500 <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_rL243500&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=EH36SVVrOANvPpWUfmtjHvcZene16JZYtYcOsOWHmmQ&s=S5dEJW-NYcq9yLglX74iN2esNypm3qfP6wCNidxysx8&e=>...assuming those don't cause new breakage, it's finally, really time to flip the FMF flag...and wait for more breakage.
>> 
>> On Mon, Jul 20, 2015 at 11:34 AM, Sanjay Patel <spatel at rotateright.com <mailto:spatel at rotateright.com>> wrote:
>> 
>> 
>> On Fri, Jul 17, 2015 at 4:42 PM, Nick Lewycky <nlewycky at google.com <mailto:nlewycky at google.com>> wrote:
>> On 9 July 2015 at 15:27, Sanjay Patel <spatel at rotateright.com <mailto:spatel at rotateright.com>> wrote:
>> Hi Nick,
>> 
>> The reciprocal fix is in at r241826. Please let me know when you find another failure. Thanks!
>> 
>> Thank you! I tested it and found exactly nothing wrong. Hopefully I didn't goof the testing, but I think it's time to flip the flag to true, then wait a few days before removing the flag entirely.
>> 
>> Wow...I'm surprised, but I'll hope for the best. Thanks for the testing!
>> 
>> 
>> Note however, that we still have problems with PR24141 which is related to unsafe fp math, but doesn't change with the -enable-fmf-dag flag.
>> 
>> Proposed fix:
>> http://reviews.llvm.org/D11345 <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11345&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=EH36SVVrOANvPpWUfmtjHvcZene16JZYtYcOsOWHmmQ&s=q0g5ELtAiUzID-3xj21ZzkiASkbrFaYCWXDy-nBF0OI&e=>
>>  
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150804/fd8f938a/attachment.html>