[PATCH] D26855: New unsafe-fp-math implementation for X86 target

Simon Pilgrim via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 9 09:10:54 PST 2017


RKSimon added a comment.

In https://reviews.llvm.org/D26855#667484, @guyblank wrote:

> In https://reviews.llvm.org/D26855#667256, @RKSimon wrote:
>
> > In https://reviews.llvm.org/D26855#667181, @guyblank wrote:
> >
> > > But I'm also concerned about other cpus for which we don't have an accurate scheduler model (broadwell, skylake), should these be excluded as well?
> >
> >
> > If the cpu is using an older scheduler model then its already not necessarily being optimally scheduled - I don't see this patch being any different.
>
>
> Currently the older schedule "only" affects the schedule, but with this patch (and future ones using the machine combiner framework) it will affect which instructions we emit. This could possibly lead to generating worse code than we do at the moment.


Recap:

This (and hopefully an equivalent sqrt/rsqrt future patch) are the stand out examples of cases that affect the actual result depending on MC and the scheduler model - minor code changes could cause it to switch between full precision divps and rcpps+nr, but this only happens with the necessary fast/unsafe flags enabled which means the user knows what to expect.

For most other possibly MC cases (e.g. constant rematerialization, shuffles, slow-vs-fast path instructions) there will be differences in the instructions used but not the final result.


https://reviews.llvm.org/D26855





More information about the llvm-commits mailing list