[llvm] r238842 - make reciprocal estimate code generation more flexible by adding command-line options (2nd try)

[Akira Hatanaka]

On Tue, Jun 2, 2015 at 3:51 PM, Sanjay Patel <spatel at rotateright.com> wrote:

> On Tue, Jun 2, 2015 at 3:40 PM, Akira Hatanaka <ahatanak at gmail.com> wrote:
>
>> On Tue, Jun 2, 2015 at 1:52 PM, Sanjay Patel <spatel at rotateright.com>
>> wrote:
>>
>>> Hi Akira,
>>>
>>> To be honest, I wasn't sure how this all works. Any advice or help is
>>> much appreciated. :)
>>>
>>> I modeled the changes for this patch on the existing
>>> FPOpFusion::FPOpFusionMode code. Does that have a corresponding function
>>> attribute? If not, how does that work for an LTO build for example?
>>>
>>>
>> As far as I can tell, FPOpFusionMode doesn't have a corresponding
>> function attribute, so it won't work for LTO builds.
>>
>>
>>> Ideally, I think that both of these would become part of the
>>> fast-math-flags that I'm trying to extend to the DAG, but a function
>>> attribute should probably be an intermediate step?
>>>
>>>
>>>
>> Yes, ideally it should be a DAG node flag. Is the undefined behavior
>> discovered when r236546 was committed still blocking progress on that work?
>>
>
> I scaled the r236546 patch back to only affect binary nodes in:
> http://reviews.llvm.org/rL237046
>
> But this patch exposed another bug that I'm hoping to get fixed with:
> http://reviews.llvm.org/D9893
>
> Unfortunately, I suspect there will be more bugs like that. They only
> become visible after FMF is added. In the commit thread for r237046, Nick
> Lewycky suggested that I should resubmit the FMF patch under an
> experimental enablement flag so it could be tested further before being
> made default. I will get that submitted again soon.
>
>
>
Using an enablement flag sounds like a good idea. I don't think we should
create a function attribute for FPopFusionMode or mrecip now, but we can
think about doing it as an intermediate step if the work to propagate the
fast math flags is going to take too long.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150603/e1e0eccd/attachment.html>