similar to: [LLVMdev] Any extend

Duncan Sands wrote: > Hi Greg, > >> 1) What causes the Initial selection DAG code to choose an any_extend >> over a sign_extend (or zero_extend)? > > because it is more efficient: the backend gets more choice in how to do > it, and at the same time it tells the optimizers that the extra bits > contain rubbish, which gives them more freedom to reason. Makes sense,

Hi Greg, > 1) What causes the Initial selection DAG code to choose an any_extend > over a sign_extend (or zero_extend)? because it is more efficient: the backend gets more choice in how to do it, and at the same time it tells the optimizers that the extra bits contain rubbish, which gives them more freedom to reason. > 2) What does any_extend actually signify? Presumably this

Hi Greg, >>> 1) What causes the Initial selection DAG code to choose an any_extend >>> over a sign_extend (or zero_extend)? >> >> because it is more efficient: the backend gets more choice in how to do >> it, and at the same time it tells the optimizers that the extra bits >> contain rubbish, which gives them more freedom to reason. > Makes sense,

At the beginning, I have the following chain: LOAD -> TRUNCATE -> ZERO_EXTEND. After Combine(BeforeLegalizeTypes) the optimization of ZERO_EXTEND gives me the new chain LOAD -> ANY_EXTEND -> AND. I want to optimize ANY_EXTEND but is not analyzed in the same Combine(). Combine(AfterLegalizeTypes) is no called at all. - Elena -----Original Message----- From: Eli Friedman

On Tue, Feb 7, 2012 at 12:38 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > At the beginning, I have the following chain: LOAD -> TRUNCATE -> ZERO_EXTEND. > After Combine(BeforeLegalizeTypes) the optimization of ZERO_EXTEND  gives me the new chain LOAD -> ANY_EXTEND -> AND. > > I want to optimize ANY_EXTEND but is not analyzed in the same Combine().

The attached patch contains: - Cleanups in the DAGCombiner.cpp ROTL/ROTR combine code, primarily helping me to fix 80col violations (benefiting the code as a whole). - Detect sign/zext/any-extended versions of ROTL/ROTR patterns. - Allow custom lowering for ROTL/ROTR (needed in the CellSPU's case for 8-bit rotates, when only 16-bit and 32-bit rotates are actually implemented in the

I linked the wrong patch review. Here's the patch that was actually committed: https://reviews.llvm.org/D48508 https://reviews.llvm.org/rL335433 On Tue, Jul 3, 2018 at 4:39 PM, Sanjay Patel <spatel at rotateright.com> wrote: > [adding back llvm-dev and cc'ing Craig] > > I think you are asking if we are missing a fold (or your target is missing > enabling another hook)

Per subject, this patch adding an additional pass to handle vector operations; the idea is that this allows removing the code from LegalizeDAG that handles illegal types, which should be a significant simplification. There are still some issues with this patch, but does the approach look sane? -Eli -------------- next part -------------- Index: lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp

Hi All, I have faced a problem with TargetLowering::SimplifyDemandedBits with AND. Here is a example as following: /* C source code */ struct A { unsigned int a; unsigned char c1, c2; bool b1 : 1; bool b2 : 1; bool b3 : 1; }; int main () { struct A x[1]; x[0].b1 = false; int s = 0; s = x[0].b1 ? 1 : 0; <--- Here is problem. if (s != 0) __builtin_abort

On Mon, Feb 6, 2012 at 11:54 PM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. > I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change

Hi, I'm trying to build code for very short function and I encounter with a problem (or bug) in DAG selection algotithm. I have a node that was created in Combine(BeforeLegalizeTypes) and should be optimized in Combine(AfterLegalizeTypes). But LegalizeTypes() did not change anything and Combine(AfterLegalizeTypes) was not called. Vector legalization that comes afterwards just scalarized the

My target has only logical shifts and lacks an arithmetic right shift instruction. I have a custom LowerSRA function that rewrites SRA as SHL + SIGN_EXTEND when the shift width is either constant 16 or 24. Unfortunately, I observe that a later pass combines the SHL + SIGN_EXTEND back into SRA so we crash. The idea I had for defeating this behavior is lower to a target-specific version of SHL

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

On Wed, May 20, 2009 at 1:19 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > Per subject, this patch adding an additional pass to handle vector > operations; the idea is that this allows removing the code from > LegalizeDAG that handles illegal types, which should be a significant > simplification.  There are still some issues with this patch, but does > the approach

Hi, I would like to restart the conversation regarding adding SVE support to LLVM. This time I am framing things from the code generation point of view because our immediate priority is llvm-mc support rather than auto-vectorisation. Can you please review the following text outlining MVT changes we would like to make so SVE instructions can be added to the AArch64 Target. My overriding

Thank you Craig for explanation. Could be the same algorithm used for custom legalizing given node in LowerOperation and ReplaceNodeResults in case results and inputs of the node are illegal? Or actually such situation is impossible and for given node either LowerOperation or ReplaceNodeResults can be only called? Przemek wt., 28 sty 2020, 18:48 użytkownik Craig Topper <craig.topper at

Hi, I am defining Hexagons version of ReplaceNodeResults to change the a node of the type A: i8 = INTRINSIC_WO_CHAIN ... , ... , To B: SIGN_EXTEND (A) After returning from my function, the type legalizer calss ReplaceValuesUsesWith to replace the uses of A with B. Unfortunately, it replaces the use of A in the new node B too. So the node now is B: SIGN_EXTEND(B) , which is clearly bad and the

-----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman Sent: Wednesday, February 18, 2009 3:01 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Possible error in LegalizeDAG On Wed, Feb 18, 2009 at 10:14 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I'm still trying to track down some