similar to: Different index types in GEPs -> non-aliasing?

Hi, On 04/18/2016 05:28 PM, Vedant Kumar wrote: > This sounds like a bug to me. > > >> // If the last (struct) indices are constants and are equal, the other indices >> // might be also be dynamically equal, so the GEPs can alias. >> if (C1 && C2 && C1 == C2) >> return MayAlias; > > Does changing this condition fix the issue? E.g

Hi Haicheng, Originally I ran into this on our out-of-tree target but I managed to reproduce the crash on X86 as well now: build-all/bin/opt -S -sroa -loop-rotate -loop-deletion -licm -loop-idiom ../llvm/bugpoint-reduced-simplified.i8+.ll gives: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at ../lib/IR/Value.cpp:696! 0 opt

Hi, I'm having a problem with GVN removing a load instruction that I think is needed. Dump before GVN: *** IR Dump Before Global Value Numbering *** ; Function Attrs: minsize optsize define i16 @TEST__MAIN(i16 %argc.13.par, i16** %argv.14.par) #0 { %buf.17 = alloca [10 x i16], align 1 %_tmp30 = getelementptr inbounds [10 x i16], [10 x i16]* %buf.17, i16 0, i16 0, !dbg !22 call

Hello everyone ! I am trying to get the dependencies for the variables of ICMP instructions. Do you know if I can use an already existing method? I tried to use getDependency() method of class MemoryDependenceAnalysis. Does it work only for particular instruction types? Its definition is MemDepResult MemoryDependenceAnalysis::getDependency ( Instruction * QueryInst ) When I running my pass

Hello. I come back to this older thread. Again, because of i64immSExt32 I receive TableGen error "Could not infer all types in, pattern!" (exact details written below). So far I'm not able to generate selection code with TableGen for the ADD_r* instructions, etc: def i64immSExt32 : PatLeaf<(imm), [{return

Hi there, the attached R function uses the SAS Integrated Object Model (IOM) and it can deal with SAS dates and long variable names. All you need to provide is the folder where the SAS data file is and the data file name without the extension. The function requires the rcom package. This is meant to be first cut...but improvements and suggestions are more than welcome! Gyula import.sas.data

I've been debugging some strange happenings over here and I put an assert in APInt to catch what I think is the source of the problem: int64_t getSExtValue() const { // An i1 -1 is unrepresentable. assert(BitWidth != 1 && "Signed i1 value is not representable!"); To me an i1 -1 makes no sense whatsoever. It is not representable in twos-complement form. It cannot

> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >> Thank you all for your replies. >> So here seems to be an agreement that the documentation for PartialAlias >> is incorrect. >> >> Daniel: now you got me wondering about MustAlias. This is what the docs >> say: >> "The MustAlias response may only be returned if the two memory objects >> are

Hello. I've tried to add some simple arithmetic vector operations to the BPF backend available in the LLVM repo. Because I added in BPFRegisterInfo.td another RegisterClass (taken from the Mips backend): def MSA128W: RegisterClass<"BPF", [v2i64, v2f64], 128, (sequence "W%u", 0, 31)>; in order to support vector for example, ADD

Introduction ============ I'm currently in the middle of what initially looked to be a simple change in GVN but is turning out to have unexpected consequences that are turning out to be quite difficult to resolve, so I thought I'd send out an RFC to make sure that I'm not barking up the wrong tree with how I'm trying to do this. Motivation and current behaviour

Hi all, I have the condition of an ICmpInst in a variable called condition obtained doing GenericValue condition = getOperandValue(&I, SF); Now I would like to understand if the comparison was true or false. Is it correct to use condition.IntVal.getSExtValue() and if the value is 0 consider the true and if the value is -1 consider the condition false? I'm not sure because I was expecting

Hi all, I want to match addition with 16bit integers. So I define a pattern fragment as follows: def simm16 : PatLeaf<(imm), [{ return isInt<16>(N->getSExtValue()); }]>; Now I am confused between (add R32:$dst, simm16:$im) and (add R32:$dst, (i32 simm16:$im)). Do both of them match the same pattern? Are they equivalent? If not what is the difference? I am also confused as to how

Hi, I've stumbled upon a case where I think gvn does a bad (wrong) optimization. It's a bit messy to debug though so I'm not sure if I should just write a PR about it a let someone who knows the code look at it instead. Anyway, for the bug to trigger I need to run the following passes in the same opt invocation: -sroa -instcombine -simplifycfg -instcombine -gvn The problem

I am processing the LLVM instructions and right now I am at the 'call' instruction. For now I just want to print the argument type. For example in the following: %0 = tail call i32 (...)* @__FFF (i32 8) nounwind; <i32> [#uses=1] I need to get access to 'i32' and '8' separately. I do: CallInst *CI = dyn_cast<CallInst>(I); Value *v = CI->getOperand(1)

Hi Nick, Thanks, that seemed to work. Nick Lewycky wrote: > > ivtm wrote: >> I am processing the LLVM instructions and right now I am at the 'call' >> instruction. >> For now I just want to print the argument type. >> >> For example in the following: >> >> %0 = tail call i32 (...)* @__FFF (i32 8) nounwind; <i32> [#uses=1]

The code below is triggering some weird behavior that's different from how gcc treats this inline asm. Clang keeps the original type of "loc" as "bool", which generates an "i1 true" after inlining. So far so good. However, during ISEL, the "true" is converted to a signed integer. So when it's evaluated, the result is this: .quad

The vnot PatFrag uses ImmAllOnesV which should put an OPC_CheckImmAllOnesV in the matcher table. And the matcher table should call ISD::isBuildVectorAllOnes. I believe we use vnot with vXi1 vectors on X86 and I haven't seen any issues. The FIXME you pointed to seems related to a scalar patcher not a vector pattern. In that case the issue is that the immediate matcher for scalars calls

Eli, Thanks for responding. Yes, I read the error message but it seems odd that it would be trying to use more than 64 bits. It compiles and executes in gcc on 32 bit arch just fine. I'll probably take your suggestion and file a bug with a reduced testcase. Thanks again, Ryan On Fri, Nov 16, 2012 at 3:10 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Nov 16, 2012

ivtm wrote: > I am processing the LLVM instructions and right now I am at the 'call' > instruction. > For now I just want to print the argument type. > > For example in the following: > > %0 = tail call i32 (...)* @__FFF (i32 8) nounwind; <i32> [#uses=1] > > I need to get access to 'i32' and '8' separately. > > I do: > >

I have an instruction: Instruction: %mask166 = and i128 %lvar_ins176, -18446462598732840961 I would like to get the value of the const above, I'm using getSExtValue; however, I obviously get an assert for "bit size" greater than 64 (since it's a i128 instruction). So how else can I get this value? Thanks. -------------- next part -------------- An HTML attachment was