[PATCH] Flag to enable IEEE-754 friendly FP optimizations

Sergey Dmitrouk via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 20 08:54:27 PDT 2015


Hi again,

On Mon, Aug 17, 2015 at 08:19:58PM +0300, Sergey Dmitrouk wrote:
> Sorry, didn't have enough time to complete this before vacation.  The reason
> it required more time is that unfortunate instruction reordering when
> floating-point operation is moved below function invocation.  You mentioned
> it in the winter, but I couldn't reproduce the issue no matter how hard I tried
> and thought that it can't happen.  After rebase three weeks ago it
> occurred for the first time allowing me to make a test for it, but defining
> operation to read/write from memory didn't fix the issue.  I left it on
> trying to find more checks that should block undesired reordering during
> instruction selection, will get back to it.

I managed to fix reordering issue in a proof-of-concept way by adding chain
to "fadd" instruction.  As you might imagine, this has quite big impact on
everything else and I even unable to tell how many tests it breaks (a lot,
some are killed, some don't finish).

I started fixing that and it requires updating every creation of nodes for
FADD, FSUB, etc. and all related permutations (mainly in DAGCombiner).  That
is like hundreds of cases, not that many overall.  Yet it seems like a big
change and I'm wondering whether this is how one should do it?  Is there any
simpler and less intrusive way of guaranteeing relative order of instructions
than adding (effectively optional) chain to floating-point instructions?

Thanks,
Sergey


More information about the llvm-commits mailing list