similar to: Disabling DAGCombine's specific optimization

Hello LLVM Developers, I am working on an architecture which have one bit shift operation if barrel shiftier hardware is not present in such cases some DAGCombine optimizations reduces performance of certain benchmarks upto 5% for example consider follwing optimization: fold (select_cc seteq (and x, y), 0, 0, A) -> (and (shr (shl x)) A) Here it introduce 2 shift operations and when barrel

Look at this silly function: $ cat small.c unsigned f(unsigned a, unsigned *p) { unsigned x = a/4; p[0] = x; p[1] = x+x; return p[1] - 2*p[0]; } GCC turns this into straightforward code and figures out the 0 return value: shrl $2, %edi movl %edi, (%rsi) addl %edi, %edi movl %edi, 4(%rsi) movl $0, %eax ret LLVM optimizes the code: $ clang -O -S -o- small.c -emit-llvm define i32

On Saturday, March 4, 2017, Ryan Taylor <ryta1203 at gmail.com> wrote: > Why you can't still expand it through MUL with a Custom lowering? Or am I > missing something? > > Yes we can but problem occurs when we know that it is shift with constant value than if we return ISD::MUL with constant imm operand than LLVM will convert it to SHL again because the constant will be

On Tue, Apr 17, 2012 at 1:36 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > I am not sure how best to fix this. If possible, InstCombine's > canonicalization shouldn't hide arithmetic progressions behind bit masks. > At least, it seems these transformations should be disabled unless (X >> > C).hasOneUse(). They aren't exactly optimizations.

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)

For any of the examples shown below, if the logical equivalent using cmp + other IR instructions is no more than the number of IR instructions as the variant that uses shift, we should consider reversing the canonicalization. To make that happen, you would need to show that at least the minimal cases have codegen that is equal or better using the cmp form for at least a few in-tree targets. My

On Tue, Apr 17, 2012 at 12:23 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > I am not sure how best to fix this. If possible, InstCombine's > canonicalization shouldn't hide arithmetic progressions behind bit masks. The entire concept of cleverly converting arithmetic to bit masks seems like the perfect domain for DAGCombine instead of InstCombine: 1) We know the

Hi, Sanjay/all, I noticed in rL331486 that some compare-select optimizations are disabled in favor of providing canonicalized cmp+select to the backend. I am currently working on a private backend target, and the target has a small code size limit. With this change, some of the apps went over the codesize limit. As an example, C code: b = (a > -1) ? 4 : 5; ll code: Before rL331486:

As before, I'm not convinced that we want to allow target-based enable/disable in instcombine for performance. That undermines having a target-independent canonical form in the 1st place. It's not clear to me what the remaining motivating cases look like. If you could post those here or as bugs, I think you'd have a better chance of finding an answer. Let's take a minimal example

Duncan: DAGCombine is inserting an IllegalOperation after target-specific instruction legalization has occurred. I'm inserting the fabs and the bitconvert during instruction legalization; DAGCombine is converting the fabs/bitconvert to an 'and' on its second (third?) pass. -scooter On Jan 20, 2009, at 12:24 AM, Duncan Sands wrote: > On Tuesday 20 January 2009 07:52:37

Hi all, I have been looking at the way LLVM optimizes code before forwarding it to the backend I develop for my company and while building define i32 @test_extract_subreg_func(i32 %x, i32 %y) #0 { entry: %conv = zext i32 %x to i64 %conv1 = zext i32 %y to i64 %mul = mul nuw i64 %conv1, %conv %shr = lshr i64 %mul, 32 %xor = xor i64 %shr, %mul %conv2 = trunc i64 %xor to i32

> I am not sure how best to fix this. If possible, InstCombine's canonicalization shouldn't hide arithmetic progressions behind bit masks. At least, it seems these transformations should be disabled unless (X >> C).hasOneUse(). They aren't exactly optimizations. > > This: > >  %div = lshr i32 %a, 2 >  store i32 %div, i32* %p, align 4, !tbaa !0 >  %add = shl

Hi Gabrielle, > > Historically nodes marked "custom" were considered legal, so the > > DAGCombiner would have been correct to generate it. Not sure how > > that ever worked though. I think Dan split the isOperationLegal > > method into isOperationLegal and isOperationLegalOrCustom for reasons > > related to this kind of thing. I don't know whether

> Historically nodes marked "custom" were considered legal, so the > DAGCombiner would have been correct to generate it. Not sure how > that ever worked though. I think Dan split the isOperationLegal > method into isOperationLegal and isOperationLegalOrCustom for reasons > related to this kind of thing. I don't know whether the DAGCombiner > is now only supposed

Hi Gabriele, > In the combine 2 step (after legalization), in the DAGCombiner::visitBIT_CONVERT() method, the DAG combiner is replacing an FABS followed by a BIT_CONVERT, to a BIT_CONVERT followed by an AND 0x7FFFFFFFFFFFFFFF. Everything is 64 bit. > On my target, FABS and BIT_CONVERT are legal in 64 bit, but AND in not legal in 64 bit (is declared custom). So the dag combiner is

> I really dislike hasOneUse-based "solutions" at the IR / InstCombine layer. > They result in strange artifacts during optimization: places where adding > similar code turns off optimizations because we fold the similar bits > together and reuse parts of the computation. > > I would much rather see us devise a reasonable set of canonicalization rules > at the IR

Hello, In the combine 2 step (after legalization), in the DAGCombiner::visitBIT_CONVERT() method, the DAG combiner is replacing an FABS followed by a BIT_CONVERT, to a BIT_CONVERT followed by an AND 0x7FFFFFFFFFFFFFFF. Everything is 64 bit. On my target, FABS and BIT_CONVERT are legal in 64 bit, but AND in not legal in 64 bit (is declared custom). So the dag combiner is introducing illegal (not

On Apr 16, 2012, at 3:30 PM, Chandler Carruth <chandlerc at google.com> wrote: > Does sinking these into the DAGCombine layer help? How much does it break? I tried disabling just the InstCombine transforms that hide shl instructions behind bitmasks. Even though DAGCombine has the same transforms, it causes some pretty bad regressions: External/SPEC/CINT95/147_vortex/147_vortex

Hi, All: I am new to R and tm package. I'm trying to do the stemming using tm_map() and it doesn't seem to work: *I used:* > stemDocument(t_cmts[[100]]) *Where t_cmts is the corpus object, the results is:* bottle loose box abt airpak sections top plastic bottle squashed nearly flush neck previous shipments bottle wrapped securely bubble wrap wno bottle damage packaging poor

On Wed, Apr 18, 2012 at 12:22 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > I tried disabling just the InstCombine transforms that hide shl > instructions behind bitmasks. Even though DAGCombine has the same > transforms, it causes some pretty bad regressions: > I wonder about your idea of still combining most of the shifts, but leaving the last bits uncombined...