llvm dev - Jan 2015 - [LLVMdev] Enable changing UnsafeFPMath on a per-function basis

We already sort of model fast math flags at per-function level by resetting
TargetOptions before selection dag is run. My proposal just makes changes
that are needed to parallelize the backend (sorry about the misleading
title of this thread).

If modeling the flags at per-instruction level is the right thing to do, I
agree that I shouldn't proceed with my current plan. I think exposing fp
flags in selection dag needs a little more work than r210467 (which exposed
nsw and nuw) did. In particular, some of the targets set operation actions
based on the value of TargetOptions::UnsafeFPMath (see
X86TargetLowering::resetOperationActions), which means legalization has to
examine the flags in addition to the opcode and type to get the operation
action.

On Tue, Jan 13, 2015 at 1:09 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
>
> On Mon, Jan 12, 2015 at 1:18 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
>
>> > Whatever happened to tracking the safe-or-fast-ness of FP math on
>> > instructions? Is tracking this property at a function granularity
>> > correct? I seem to recall nobody wanted to thread this through the
>> > SDAG.
>>
>> No, I think we did want to do that, just no one has yet done it. We now
>> have NSW/NUW in SDAG, so it should not be too much different for the FP
>> flags.
>
>
> FWIW, I think it is a mistake to pursue the per-function modeling of this
> given how close we are to having proper per-instruction tracking of this. I
> would much rather see work going toward that if we think that is the right
> long-term thing for LLVM...
>
> If this is super simple to do for per-function granularity, cool. But if
> it is adding lots of complexity (which I'm worried about with Chris
B's
> comments below) I think it makes more sense to focus on doing per-DAG-node
> fast math flags.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/0cec3f2d/attachment.html>

On Wed, Jan 14, 2015 at 12:28 PM, Akira Hatanaka <ahatanak at gmail.com>
wrote:
> If modeling the flags at per-instruction level is the right thing to do

Long term, I definitely think this is the right way to go. It lets us
optimize code which has been inlined from an unsafe fp math function into a
normal function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/54933854/attachment.html>

> On Jan 14, 2015, at 12:53 PM, Chandler Carruth <chandlerc at
google.com> wrote:
> 
> 
> On Wed, Jan 14, 2015 at 12:28 PM, Akira Hatanaka <ahatanak at gmail.com
<mailto:ahatanak at gmail.com>> wrote:
> If modeling the flags at per-instruction level is the right thing to do
> 
> Long term, I definitely think this is the right way to go. It lets us
optimize code which has been inlined from an unsafe fp math function into a
normal function.
Is there a thread that already discuss that other than the two years old one I
found: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-October/054999.html

Thanks,

Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/96ed02f8/attachment.html>

On Wed, Jan 14, 2015 at 1:53 PM, Chandler Carruth <chandlerc at
google.com>
wrote:
>
> On Wed, Jan 14, 2015 at 12:28 PM, Akira Hatanaka <ahatanak at
gmail.com>
> wrote:
>
>> If modeling the flags at per-instruction level is the right thing to do
>
>
> Long term, I definitely think this is the right way to go. It lets us
> optimize code which has been inlined from an unsafe fp math function into a
> normal function.
>
Instruction-level FMF has potential benefits beyond just inlined code. A
couple of recent examples posted here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/080364.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150114/158388b1/attachment.html>