I see. We still can use that shortcut to catch the simple case after type legalization, but we could also do a more elaborate type check before type legalization to enable it? On Aug 19, 2013, at 4:13 PM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com> wrote: > Hi @ll, > > I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG combines until after the Legalizer has run. If the IR has already only legal types the second round of DAG combines is skipped and no VSELECT specified optimizations are performed at all. > > Is there a reason we don’t run the X86 DAG combiner before Type Legalization? > > I think the code in question is using isBeforeLegalize as a shortcut for "are all the operand and result types legal". > > -Eli-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130819/e62c2f68/attachment.html>
On Mon, Aug 19, 2013 at 4:17 PM, Juergen Ributzka <juergen at apple.com> wrote:> I see. We still can use that shortcut to catch the simple case after type > legalization, but we could also do a more elaborate type check before type > legalization to enable it? >If you're going to write the code to check the types anyway, it's probably clearer to remove the isBeforeLegalize check. -Eli> On Aug 19, 2013, at 4:13 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com>wrote: > >> Hi @ll, >> >> I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine >> in the X86 backend. This defers all VSELECT related DAG combines until >> after the Legalizer has run. If the IR has already only legal types the >> second round of DAG combines is skipped and no VSELECT specified >> optimizations are performed at all. >> >> Is there a reason we don’t run the X86 DAG combiner before Type >> Legalization? > > > I think the code in question is using isBeforeLegalize as a shortcut for > "are all the operand and result types legal". > > -Eli > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130819/029984ee/attachment.html>
Can this optimization be moved to the lowering phase? LowerVSELECT() ? - Elena From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Tuesday, August 20, 2013 03:56 To: Juergen Ributzka Cc: Benjamin Kramer; LLVM Developers Mailing List Subject: Re: [LLVMdev] [X86] DAG Combine - VSELECT On Mon, Aug 19, 2013 at 4:17 PM, Juergen Ributzka <juergen at apple.com<mailto:juergen at apple.com>> wrote: I see. We still can use that shortcut to catch the simple case after type legalization, but we could also do a more elaborate type check before type legalization to enable it? If you're going to write the code to check the types anyway, it's probably clearer to remove the isBeforeLegalize check. -Eli On Aug 19, 2013, at 4:13 PM, Eli Friedman <eli.friedman at gmail.com<mailto:eli.friedman at gmail.com>> wrote: On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at apple.com<mailto:juergen at apple.com>> wrote: Hi @ll, I am wondering about the use of !isBeforeLegalize in PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG combines until after the Legalizer has run. If the IR has already only legal types the second round of DAG combines is skipped and no VSELECT specified optimizations are performed at all. Is there a reason we don't run the X86 DAG combiner before Type Legalization? I think the code in question is using isBeforeLegalize as a shortcut for "are all the operand and result types legal". -Eli --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130820/819f964b/attachment.html>
Sorry, took me a little longer to come back to this.
The attached patch enables X86 VSELECT DAG combines before DAG type
legalization.
Cheers,
Juergen
On Aug 19, 2013, at 5:56 PM, Eli Friedman <eli.friedman at gmail.com>
wrote:
> On Mon, Aug 19, 2013 at 4:17 PM, Juergen Ributzka <juergen at
apple.com> wrote:
> I see. We still can use that shortcut to catch the simple case after type
legalization, but we could also do a more elaborate type check before type
legalization to enable it?
>
> If you're going to write the code to check the types anyway, it's
probably clearer to remove the isBeforeLegalize check.
>
> -Eli
>
> On Aug 19, 2013, at 4:13 PM, Eli Friedman <eli.friedman at gmail.com>
wrote:
>
>> On Mon, Aug 19, 2013 at 3:34 PM, Juergen Ributzka <juergen at
apple.com> wrote:
>> Hi @ll,
>>
>> I am wondering about the use of !isBeforeLegalize in
PerformSELECTCombine in the X86 backend. This defers all VSELECT related DAG
combines until after the Legalizer has run. If the IR has already only legal
types the second round of DAG combines is skipped and no VSELECT specified
optimizations are performed at all.
>>
>> Is there a reason we don’t run the X86 DAG combiner before Type
Legalization?
>>
>> I think the code in question is using isBeforeLegalize as a shortcut
for "are all the operand and result types legal".
>>
>> -Eli
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130821/596190b3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: X86DAGCombine.diff
Type: application/octet-stream
Size: 3781 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130821/596190b3/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130821/596190b3/attachment-0001.html>