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

[Sanjay Patel]

On Wednesday, June 3, 2015, Akira Hatanaka <ahatanak at gmail.com> wrote:

> On Tue, Jun 2, 2015 at 3:51 PM, Sanjay Patel <spatel at rotateright.com
> <javascript:_e(%7B%7D,'cvml','spatel at rotateright.com');>> wrote:
>
>> On Tue, Jun 2, 2015 at 3:40 PM, Akira Hatanaka <ahatanak at gmail.com
>> <javascript:_e(%7B%7D,'cvml','ahatanak at gmail.com');>> wrote:
>>
>>> On Tue, Jun 2, 2015 at 1:52 PM, Sanjay Patel <spatel at rotateright.com
>>> <javascript:_e(%7B%7D,'cvml','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.
>

Thanks, Akira. I'll keep stumbling along this path then. Note that this
patch (mrecip) was also reverted again, so I'm just trying to get any
change to stick at this point!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150603/15d05acf/attachment.html>