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

[Sanjay Patel]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150602/9fb5ffc3/attachment.html>