[LLVMdev] Stop MachineCSE on certain instructions
Jim Grosbach
grosbach at apple.com
Tue Dec 20 11:11:04 PST 2011
Hi Girish,
Sorry, but I'm afraid I don't understand your question. Can you elaborate a bit?
-Jim
On Dec 19, 2011, at 9:12 PM, girish gulawani wrote:
>
> Hello Jim.
> Just out of curiosity, won't such mechanism work via the patterns from instructions defs?
>
> Thanks.
> Girish.
>
> From: Jim Grosbach <grosbach at apple.com>
> To: Johannes Birgmeier <e0902998 at student.tuwien.ac.at>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Monday, 19 December 2011 10:33 PM
> Subject: Re: [LLVMdev] Stop MachineCSE on certain instructions
>
> Hi Johannes,
>
> You may be interested in the (very) recently added explicit instruction bundle support. For an example of their usage, have a look at the ARM backend's IT-block (Thumb2 predication support) pass, which uses them to tie instructions together.
>
> -Jim
>
> On Dec 17, 2011, at 12:24 PM, Johannes Birgmeier wrote:
>
> > Hello,
> >
> > I'm writing for a backend and have a complicated instruction bundle (3
> > instructions) that has to be executed like a single block (meaning: if
> > the first instruction is executed, all three have to be executed to
> > obtain the result, though not necessarily without other instructions in
> > between). Unfortunately, MachineCSE gets in the way sometimes and rips
> > it apart.
> >
> > Is there a way to stop CSE from doing its thing (common subexpression
> > elimination) for certain instructions?
> >
> > I've already tried glueing (gluing?) them together, but that doesn't
> > seem to make a difference.
> >
> > Regards,
> > Johannes Birgmeier
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
More information about the llvm-dev
mailing list