[llvm-commits] [llvm] r163035 - in /llvm/trunk: lib/Target/X86/X86InstrFMA.td lib/Target/X86/X86InstrInfo.cpp test/CodeGen/X86/fma_patterns.ll

Craig Topper craig.topper at gmail.com
Tue Sep 4 15:00:52 PDT 2012


On Tue, Sep 4, 2012 at 2:27 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:

>
> On Sep 4, 2012, at 12:20 PM, Craig Topper <craig.topper at gmail.com> wrote:
>
> > The default implementation of findCommutedOpIndices returns the first
> two input operands which works for these instructions. We also have
> precedent in the commuting of SHRD and SHLD instructions which have a third
> immediate argument. They have partial custom code, but don't change from
> the default implementation of findCommutedOpIndices.
> >
> > I made them commutable so that TwoAddressInstructionPass and
> optimizeLoadInstr can better optimize them.
>
> I see. Thanks.
>
> > We can still do better here because there are 3 different FMA3 opcodes
> that vary which operand is the destructive dest and where the load can be
> folded. Not sure the best way to work some of that into the infrastructure
> without creating a new pass. I'd appreciate any input you have on that.
>
> I am not sure how that would work. Preferably, the destructive def should
> be tied to a use that is also a kill.
>

Right. Effectively the 3 different opcodes provide all possible flavors of
commuting of 3 operands. So somewhere we need to decide which of the 6
possible commute choices for 3 operands is appropriate. The existing
infrastructure is obviously only designed for 2 possibilities.


>
> /jakob
>
>


-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120904/d2c342ac/attachment.html>


More information about the llvm-commits mailing list