<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On 9 Jan 2018 22:55, "John McCall via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div class="quoted-text"><blockquote type="cite"><div>On Jan 9, 2018, at 3:50 PM, Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>> wrote:</div><br class="m_-757546343991906424Apple-interchange-newline"><div><div class="m_-757546343991906424WordSection1" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">>The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining;<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">>unless you're going to prevent functions that use stricter/laxer FP rules from being inlined >into<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">>each other (which sounds disastrous), you're going to need to communicate strictness on an<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">>instruction-by-instruction basis. If the backend wants to handle that by using the strictest<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">>rule that it sees in use anywhere in the function because pattern-matching is otherwise too<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">>error-prone, ok, that's its right; but the IR really should be per-instruction.<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I added a function level attribute, strictfp, which is meant to help with this. I don’t believe the inlining handling of the attribute is implemented yet, but what I’m thinking is that we would never inline a function that had the strictfp attribute and if we inlined a non-strictfp function into a strictfp function, we would transform any FP operations into their constrained equivalents at that time. In the short term, we’d probably just block both types of inlining.<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It may sound disastrous, but I think there’s an understanding that using strict FP semantics is going to significantly inhibit optimizations. In the short term, that’s actually the purpose of the constrained intrinsics -- to disable all optimizations until we can teach the optimizer to do things correctly. The plan is that once this is all implemented to produce correct results, we’ll go back and try to re-enable as many optimizations as possible, which may eventually include doing something more intelligent with inlining.<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">With regard to your “instruction level” comments, my intention is that the use of the intrinsics will impose the necessary restrictions at the instruction level. Optimizations (other than inlining) should never need to check the function level attribute. But if we mixed “raw” FP operations and constrained intrinsics within a single function there would be no way to prevent motion of the “raw” operations across the intrinsics.</span></div></div></div></blockquote><div><br></div></div>Is that a problem? Semantics are guaranteed only for strictfp operations, i.e. ones that use the intrinsics. Raw operations can get reordered across intrinsics and change semantics, but that seems allowable, right?</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">No. Raw operations must execute in the default FP environment. It's not ok to reorder a raw fp operation into an FENV_ACCESS region and past a call that enables an FP exception on overflow, for example.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>John.</div><div class="elided-text"><div><br></div><div><br><blockquote type="cite"><div><div class="m_-757546343991906424WordSection1" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">The reason I brought up the scope level nature of the pragma was just to suggest that it might be a property that we could take advantage of to handle the transition from IR to MIR. I haven’t come up with a way to bake the strict FP information into the instructions across the ISel boundary, but I think it might be possible to temporarily add it to a block and then have an early machine code pass that used this information in some way once the MIR was all in place. I’m open to the possibility that that was a bad idea.<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">-Andy<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><a name="m_-757546343991906424__MailEndCompose"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></a></div><div><div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:Calibri,sans-serif"><span class="m_-757546343991906424Apple-converted-space"> </span><a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a> [<a href="mailto:rjmccall@apple.com" target="_blank">mailto:rjmccall@apple.com</a>]<span class="m_-757546343991906424Apple-converted-space"> </span><br><b>Sent:</b><span class="m_-757546343991906424Apple-converted-space"> </span>Tuesday, January 09, 2018 11:12 AM<br><b>To:</b><span class="m_-757546343991906424Apple-converted-space"> </span>Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>><br><b>Cc:</b><span class="m_-757546343991906424Apple-converted-space"> </span>Ulrich Weigand <<a href="mailto:Ulrich.Weigand@de.ibm.com" target="_blank">Ulrich.Weigand@de.ibm.com</a>>; <a href="mailto:kpn@neutralgood.org" target="_blank">kpn@neutralgood.org</a>; <a href="mailto:bumblebritches57@gmail.com" target="_blank">bumblebritches57@gmail.com</a>; <a href="mailto:bob.huemmer@sas.com" target="_blank">bob.huemmer@sas.com</a>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>>; <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><b>Subject:</b><span class="m_-757546343991906424Apple-converted-space"> </span>Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?<u></u><u></u></span></div></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><u></u> <u></u></div><div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">On Jan 9, 2018, at 1:53 PM, Kaylor, Andrew via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<u></u><u></u></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><u></u> <u></u></div><div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">I think we’re going to need to create a new mechanism to communicate strict FP modes to the backend. I think we need to avoid doing anything that will require re-inventing or duplicating all of the pattern matching that goes on in instruction selection (which is the reason we’re currently dropping that information). I’m out of my depth on this transition, but I think maybe we could handle it with some kind of attribute on the MBB.</span><u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">In C/C++, at least, it’s my understanding that the pragmas always apply at the scope-level (as opposed to having the possibility of being instruction-specific), and we’ve previously agreed that our implementation will really need to apply the rules across entire functions in the sense that if any part of a function uses the constrained intrinsics all FP operations in the function will need to use them (though different metadata arguments may be used in different scopes). So I think that opens our options a bit.</span><u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Regarding constant folding, I think you are correct that it isn’t happening anywhere in the backends at the moment. There is some constant folding done during instruction selection, but the existing mechanism prevents that. My concern is that given LLVM’s development model, if there is nothing in place to prevent constant folding and no consensus that it shouldn’t be allowed then we should probably believe that someone will eventually do it.</span><u></u><u></u></div></div></div></blockquote><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><u></u> <u></u></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">The standard argument against trying to introduce "scope-like" mechanisms to LLVM IR is inlining; unless you're going to prevent functions that use stricter/laxer FP rules from being inlined into each other (which sounds disastrous), you're going to need to communicate strictness on an instruction-by-instruction basis. If the backend wants to handle that by using the strictest rule that it sees in use anywhere in the function because pattern-matching is otherwise too error-prone, ok, that's its right; but the IR really should be per-instruction.<u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><u></u> <u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif">John.<u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><br><br><u></u><u></u></div><blockquote style="margin-top:5pt;margin-bottom:5pt"><div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">-Andy</span><u></u><u></u></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> </span><u></u><u></u></div></div><div><div style="border-style:solid none none;border-top-width:1pt;border-top-color:rgb(225,225,225);padding:3pt 0in 0in"><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><b><span style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span class="m_-757546343991906424apple-converted-space"><span style="font-size:11pt;font-family:Calibri,sans-serif"> </span></span><span style="font-size:11pt;font-family:Calibri,sans-serif">Ulrich Weigand [<a href="mailto:Ulrich.Weigand@de.ibm.com" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">mailto:Ulrich.Weigand@de.ibm.<wbr>com</span></a>]<span class="m_-757546343991906424apple-converted-space"> </span><br><b>Sent:</b><span class="m_-757546343991906424apple-converted-space"> </span>Tuesday, January 09, 2018 9:59 AM<br><b>To:</b><span class="m_-757546343991906424apple-converted-space"> </span>Kaylor, Andrew <<a href="mailto:andrew.kaylor@intel.com" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">andrew.kaylor@intel.com</span></a>>;<span class="m_-757546343991906424apple-converted-space"> </span><a href="mailto:kpn@neutralgood.org" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">kpn<wbr>@neutralgood.org</span></a><br><b>Cc:</b><span class="m_-757546343991906424apple-converted-space"> </span>Hal Finkel <<a href="mailto:hfinkel@anl.gov" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">hfinkel@anl.gov</span></a>>; Richard Smith <<a href="mailto:richard@metafoo.co.uk" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">richard@metafoo.co.uk</span></a>>;<span class="m_-757546343991906424apple-converted-space"> </span><a href="mailto:bob.huemmer@sas.com" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">bob.<wbr>huemmer@sas.com</span></a>;<span class="m_-757546343991906424apple-converted-space"> </span><a href="mailto:bumblebritches57@gmail.com" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">bumblebritche<wbr>s57@gmail.com</span></a>;<span class="m_-757546343991906424apple-converted-space"> </span><a href="mailto:wei.ding2@amd.com" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">wei.ding2@amd.<wbr>com</span></a>;<span class="m_-757546343991906424apple-converted-space"> </span><a href="mailto:cfe-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">cfe-dev@lists.llvm.org</span></a>; llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank"><span style="color:rgb(149,79,114)">llvm-dev@lists.llvm.org</span></a>><br><b>Subject:</b><span class="m_-757546343991906424apple-converted-space"> </span>Re: [cfe-dev] Why is #pragma STDC FENV_ACCESS not supported?</span><u></u><u></u></div></div></div></div><div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"> <u></u><u></u></div></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:10pt">Andrew Kaylor wrote:</span><br><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>In general, the current "strict FP" handling stops at instruction</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>selection. At the MachineIR level we don't currently have a mechanism</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>to prevent inappropriate optimizations based on floating point</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>constraints, or indeed to convey such constraints to the backend.</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>Implicit register use modeling may provide some restriction on some</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>architectures, but this is definitely lacking for X86 targets. On the</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>other hand, I'm not aware of any specific current problems, so in many</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>cases we may "get lucky" and have the correct thing happen by chance.</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>Obviously that's not a viable long term solution. I have a rough plan</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>for adding improved register modeling to the X86 backend, which should</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>take care of instruction scheduling issues, but we'd still need a</span></tt><br><tt style="font-family:'Courier New'"><span style="font-size:10pt">>mechanism to prevent constant folding optimizations and such.</span></tt><br><span style="font-size:10pt"><br>Given that Kevin intends to target SystemZ, I'll be happy to work on the SystemZ back-end support for this feature. I agree that we should be using implicit control register dependencies, which will at least prevent moving floating-point operations across instructions that e.g. change rounding modes. However, the main property we need to model is that floating-point operations may *trap*. I guess this can be done using UnmodeledSideEffects, but I'm not quite clear on how to make this dependent on whether or not a "strict" operation is requested (without duplicating all the instruction patterns ...).</span><br><br><span style="font-size:10pt">Once we do use something like UnmodeledSideEffects, I think MachineIR passes should handle everything correctly; in the end, the requirements are not really different from those of other trapping instructions. B.t.w. I don't think anybody does constant folding on floating-point constants at the MachineIR level anyway ... have you seen this anywhere?</span><br><br><span style="font-size:10pt"><br>Mit freundlichen Gruessen / Best Regards<br><br>Ulrich Weigand<br><br>--<span class="m_-757546343991906424apple-converted-space"> </span><br>Dr. Ulrich Weigand | Phone: <a href="tel:+49%207031%20163727" value="+497031163727" target="_blank">+49-7031/16-3727</a><br>STSM, GNU/Linux compilers and toolchain<br>IBM Deutschland Research & Development GmbH<br>Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp<br>Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294</span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:'Times New Roman',serif"><span style="font-size:9pt;font-family:Helvetica,sans-serif">______________________________<wbr>_________________<br>cfe-dev mailing list<br></span><a href="mailto:cfe-dev@lists.llvm.org" style="color:purple;text-decoration:underline" target="_blank"><span style="font-size:9pt;font-family:Helvetica,sans-serif;color:rgb(149,79,114)">cfe-dev@lists.llvm.org</span></a><span style="font-size:9pt;font-family:Helvetica,sans-serif"><br></span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" style="color:purple;text-decoration:underline" target="_blank"><span style="font-size:9pt;font-family:Helvetica,sans-serif;color:rgb(149,79,114)">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</span></a></div></div></blockquote></div></div></div></blockquote></div><br></div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div></div>