similar to: [LLVMdev] inconsistent wording in the LangRef regarding "shl nsw"

Sorry, the old title didn't make sense. > Hi, > > I have doubts on the following transformation in InstCombineAddSub.cpp. Is > it always safe to preserve NSW/NUW in this case? > > // If this is a 'B = x-(-A)', change to B = x+A. This preserves NSW/NUW. if (Value

> I wouldn't be surprised if InstSimplify were relying on (1) to implement > some of its optimizations: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/InstructionSimplify.cpp?revision=233938&view=markup#l2298 Yup! It looks like LLVM really implements (1) and (2) is just a misleading anecdote. So I'll change my vote from "remove (1)" to "remove

Hello to everybody, I'm working on some improvements on trip count computation with ScalarEvolution analysis. Considering the following test ;----------------------------------------------------------------------------; define void @foo(i32 %a, i32 %b, i32 %s) #0 { entry: %cmp = icmp sgt i32 %s, 0 %cmp15 = icmp sgt i32 %a, %b %or.cond = and i1 %cmp, %cmp15 br i1 %or.cond, label

On Oct 1, 2013, at 6:45 AM, Michele Scandale <michele.scandale at gmail.com> wrote: > Hello to everybody, > > I'm working on some improvements on trip count computation with ScalarEvolution > analysis. > Considering the following test > > ;----------------------------------------------------------------------------; > define void @foo(i32 %a, i32 %b, i32 %s) #0

Re-adding the list, below message was sent to me alone: On 11 August 2011 13:45, Rinaldini Julien <julien.rinaldini at heig-vd.ch> wrote: > Thx for all answers... > > I'll try that. But in a long term what I want to do will be a bit more complicated... It was just an example. In this case, the goal is to replace all add with sub that return the same result, like: > > var

Hi, I have a question about the llvm passes. I'm iterating over a basicblock and I can get an instruction and print it. Now, I want to iterate over the instruction and be able to modify the values of the instruction. For example, if my instruction is an add "<result> = add i32 4, %var" I want to transform it in a sub "<result> = sub i32 4, %var". I looked up

----- Original Message ----- > > On Oct 1, 2013, at 6:45 AM, Michele Scandale > <michele.scandale at gmail.com> wrote: > > > Hello to everybody, > > > > I'm working on some improvements on trip count computation with > > ScalarEvolution > > analysis. > > Considering the following test > > > >

Hi, We have recently encountered incorrect code generation issues and I think it is a SCEVExpander bug exposed by a recent patch to add nuw/nsw flags when generating code for SCEVMulExpr. The test case IR looks like this- %1 = load i16, i16* %arrayidx %2 = and i16 %1, -32768 The SCEV form of %2 is this- (-32768 * (%1 /u -32768))<nuw><nsw> It has both nsw/nuw flags. The signed

Yes - this has been in InstCombine for a long time: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp#L268 We could say that the canonicalization should be reversed, but that probably uncovers more missing optimizations. The code size concern is legitimate. For example on x86, gcc asm is 2 bytes smaller on this example:

Thanks for your reply. We are propagating sign info to tablegen currently using BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm. I imagine (I have not looked) they are printed according to instruction in AsmPrinter.cpp (pure speculation). I'm still confused as to why 0x7FFF is ok to match 16 bit int but not 0x8000? Thanks. On Wed, Feb 15, 2017 at 1:44 PM, Manuel Jacob <me at

Where does the unsignedSub come from? On 2017-02-15 20:38, Ryan Taylor wrote: > Sorry, it should be: > > defm SUB16u_ : ABD_NonCommutative<"sub16u", unsignedSub, LOADRegs, > GPRRegs, DSTRegs, i16, i16, i16, uimm16, immZExt16x>; > > On Wed, Feb 15, 2017 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> > wrote: > >> I see. If I put simm16 and

I've been doing some digging in this area (scev, wrapping arithmetic), learning as much as I can, and have reached a point where I'm fairly confused about the semantics of nuw in scalar evolution expressions. Consider the following program: define void @foo(i32 %begin) { entry: br label %loop loop: %idx = phi i32 [ %begin, %entry ], [ %idx.dec, %loop ] %idx.dec = sub nuw i32

Thanks. I have checked the hook DAGCombiner::isMulAddWithConstProfitable And I think the above condition is too aggressive. // If the add only has one use, this would be OK to do. if (AddNode.getNode()->hasOneUse()) return true; Shall we make it to if (AddNode.getNode()->hasOneUse() && TargetLowering.isCheaperCommuteAddMul(......)) return true; The virtual hook

I see. If I put simm16 and immSExt16x in place of uimm16 and immZExt16x respectively, the imm matches but it prints out -32768 (which is invalid for sub16u). We are using uimm16 not match unsigned but for PrintMethod, effectively uimm16 and simm16 are both Operand<i16>. I'm still unclear why simm16 matches and uimm16 does not. Here is the pattern if that helps at all. So just as a

Hi, James, Thanks for your reply. I do not think it is always true, that "mul then add" is faster than "add then mul". For example, A small immediate can be directly encoded in the instruction, but it becomes a larger one after a multiplication, which has to be loaded from the constant pool (extra memory access). So I wonder, is it possile to prevent it, via changes

Hi. There are few one-line bugs Andrey Karpov have found with static analisys. He wrote a big article in russian on http://habrahabr.ru/blogs/compilers/125626/ for advertising purposes of static analyzer for Visual Studio his company developed. Most of the problems are easy to fix, so I list them in here for trunk version. Also few problems in clang code were found, I don't list them in here.

Hi Lockal S, > ---- > > lib/Target/X86/X86ISelLowering.cpp:11689 > !DAG.isKnownNeverZero(LHS)&& !DAG.isKnownNeverZero(LHS)) > > Note that there are identical subexpressions '!DAG.isKnownNeverZero (LHS)' to > the left and to the right of the '&&' operator. > The second subexpression should probably be !DAG.isKnownNeverZero(RHS)). a patch

Hi, one of the greendragon bots is flaky due to mmap_stress.cc in compiler-rt. In the last two days this bot failed three times (and recovered) due to thhe mmap_stress.cc test in compiler-rt: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9557/testReport/ http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA_check/9551/testReport/

On Sat, Apr 29, 2017 at 12:46 PM, Karol Herbst <karolherbst at gmail.com> wrote: > helps two alien isolation shaders > > shader-db: > total instructions in shared programs : 4251497 -> 4251494 (-0.00%) > total gprs used in shared programs : 513962 -> 513962 (0.00%) > total local used in shared programs : 29797 -> 29797 (0.00%) > total bytes used in shared

On Sat, Apr 29, 2017 at 6:09 PM, Karol Herbst <karolherbst at gmail.com> wrote: > helps two alien isolation shaders > > shader-db: > total instructions in shared programs : 4251497 -> 4251494 (-0.00%) > total gprs used in shared programs : 513962 -> 513962 (0.00%) > total local used in shared programs : 29797 -> 29797 (0.00%) > total bytes used in shared