similar to: [LLVMdev] Question about dag-combine pass

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

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

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

Disabling this optimization in the DAG combiner isn't going to eliminate the problem; instcombine, GVN, and maybe even others also happen to perform this optimization. You may find it more effective to look for ways for codegen to recover in these kinds of situations. Dan On Mar 19, 2009, at 10:38 AM, Alireza.Moshtaghi at microchip.com wrote: > Some of the optimizations that the first

Is there an established way of disabling a DAG combine on a per target basis, where it appears to be detrimental to the generated code? Writing if (!mytarget) in DAGCombiner.cpp works but tends to be erased by git merge and generally doesn't look ideal. Writing the inverse transform in target specific code doesn't work in this instance and in general creates an infinite loop. Guidance

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

On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com>wrote: > Hi, > > ** Problematic ** > I am looking for advices to share some logic between DAG combine and > target lowering. > > Basically, I need to know if a bitcast that is about to be inserted during > target specific isel lowering will be eliminated during DAG combine. > > Let me

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

Some of the optimizations that the first DAG combine performs is counter productive for our 8-bit target. For example in: // I dropped the types because they are irrelevant. // Excuse me for changing the syntax... store %tmp1, %var %tmp2 = load %var %tmp4 = add %tmp3, %tmp2 Since load is the only user of var and since var has just be stored to, it assumes that %tmp1 is alive and it goes ahead

The code sequence: > store %tmp1, var > > tmp4 = add %tmp3 , %tmp1 > can happen even if you eliminate the specific dag combine in question. The real solution lies elsewhere. To me, this seems more like a register allocation problem. Evan On Mar 22, 2009, at 9:39 PM, Alireza.Moshtaghi at microchip.com wrote: > I can't think of any workaround? this optimization eliminates

Hi, ** Problematic ** I am looking for advices to share some logic between DAG combine and target lowering. Basically, I need to know if a bitcast that is about to be inserted during target specific isel lowering will be eliminated during DAG combine. Let me know if there is another, better supported, approach for this kind of problems. ** Motivating Example ** The motivating example comes

On Mon, Jul 1, 2013 at 1:33 PM, Quentin Colombet <qcolombet at apple.com>wrote: > On Jul 1, 2013, at 11:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com> > wrote: > >> Hi, >> >> ** Problematic ** >> I am looking for advices to share some logic between DAG

Remember, our target does not have registers like ordinary processors do. So register allocation is really not going to do much for us. What we have to do is to exploit the existing opportunities in the source code and try to generate code based on such opportunities. The dag combination in question is one such opportunity that is being destroyed by the optimization. You maybe right in that this

On Jul 1, 2013, at 11:52 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Mon, Jul 1, 2013 at 11:30 AM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi, > > ** Problematic ** > I am looking for advices to share some logic between DAG combine and target lowering. > > Basically, I need to know if a bitcast that is about to be inserted during target

I can't think of any workaround? this optimization eliminates so much information that if we want to retrieve back, it will take a lot of processing and may not necessarily be able to retrieve the lost information for all cases. Besides, why does the generic part of llvm have to force an optimization that is counter productive to some targets? If there are other phases that do the same

Dear all r-users, Suppose I have two data frame: A 1 3 4 5 2 and B 5 6 3 5 Now I want combine this two data frames without losing any value from either data frame. More precisely I want to see A B 1 5 3 6 4 3 5 5 2 NA I tried with cbind function but failed, as it only works when two data frames have equal number of rows. Can anyone suggest me any code that can be used for any

Hi llvm-dev, I just tried to implement a target-specific dag combine to preempt a generic dag combine, and I was surprised to see that it didn't work because the generic dag combines are run first. Does anyone know the rationale for running the generic dag combines first? I would have expected the target dag combines to run first because they have more specific information about what combines

On Thu, May 16, 2013 at 02:03:14AM +0000, Martin Filteau wrote: > Hi all, > > It's the first LLVM backend we do for our asynchronous DSP. So, I apologize if this is a trivial question! > > The target-independent DAG combiner performs the following transformation: > > sub n, c -> add n, -c > It looks to me like this transformation would happen

Hi all, It's the first LLVM backend we do for our asynchronous DSP. So, I apologize if this is a trivial question! The target-independent DAG combiner performs the following transformation: sub n, c -> add n, -c For our target, negative constants are more costly to encode. What is the best place to revert to a sub instruction? Kind regards, -- Martin

A better way to handle this is to a td pattern to match "add n, -c" to a subtraction. I believe several targets do something similar to this. Evan On May 16, 2013, at 7:12 AM, Tom Stellard <tom at stellard.net> wrote: > On Thu, May 16, 2013 at 02:03:14AM +0000, Martin Filteau wrote: >> Hi all, >> >> It's the first LLVM backend we do for our asynchronous