similar to: [LLVMdev] Why are imm shifts where imm >= width type eliminated entirely?

Ok, this makes sense. So, my follow up is then why, as in Mips, R600, etc... the bit value is checked in the tablegen. Seems that we should expect it to fit anyways if it still exists at this point? I'm having a hard time trying to get shl to take a PatLeaf for Imm instead of an ImmLeaf. On Mon, Apr 20, 2015 at 4:11 PM, David Majnemer <david.majnemer at gmail.com> wrote: > >

On 04/20/2015 01:25 PM, David Majnemer wrote: > These optimizations are not always run on IR that is fed to the backend. The DAG combiner also performs the undefined shift -> undef though, so it should still be OK -Matt

There can also be other “problems" like this one: http://reviews.llvm.org/D6946 <http://reviews.llvm.org/D6946> - Matthias > On Apr 20, 2015, at 1:44 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >> The DAG combiner also performs the undefined shift -> undef though, so it >> should still be OK > > DAG combiner doesn't really run to

Hi Can someone explain to me why we cant use uint64_t for extractvalue and insertvalue indices, while GEP on arrays can have indices of any integer type. Basically if I load an array with UINT_MAX+O (O>=2) elements, I can not extract its last element. Given this restriction I feel we have a bug here (uint64_t is passed as a unsigned). This cant happen because of the if (NumElements > 1024)

Hi all, We noticed a lot of unnecessary ptrtoint instructions that stand in way of some of our optimizations; the code pattern looks like this: bb1: %int1 = ptrtoint %struct.s* %ptr1 to i64 bb2: %int2 = ptrtoint %struct.s* %ptr2 to i64 %bb3: %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ] %ptr = inttoptr i64 %phi.node to %struct.s* In short, the pattern above arises due to: 1.

Hi, I’ve recently encountered an issue where the `instcombine` pass replaces an `llvm.memcpy` between two distinct address spaces with an `addrspacecast` instruction. As an example, see the trivial OpenCL kernel attached. I’m compiling like this: clang -cc1 -triple spir64-unknown-unknown -x cl -O0 -emit-llvm array_init.cl -o before.ll This yields an `llvm.memcpy` to copy the array

On 07/09/12 18:13, Chris Lattner wrote: > On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, "Jingyue Wu" <jingyue at google.com> > Sent: Wednesday, July 1, 2015 2:27:59 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > >

Hi Mehdi, Thanks for the reply - I’ve finally got round to trying to fix this based on your suggestion. I’ve got something that mostly works, but I just wanted to double-check something about the regression tests before I post a patch. > The memcpy is supposed to be equivalent to a sequence of load and store. Here we are just failing to keep the property that the load is performed through

On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow (e.g. the maximum preferred alignment across all

My general feeling is this: No optimizations should be creating int2ptr/ptr2int. We really need to fix them all. They should use pointer casts and i8* GEPs. This has, unfortunately, been a problem for a long time. As Johannes says, optimizing int2ptr/ptr2int is very tricky. In part, becaue all dependencies, including implicit control dependencies, end up being part of the resulting aliasing

On 06/09/12 20:24, Chris Lattner wrote: > On Sep 6, 2012, at 8:51 AM, Richard Osborne <richard at xmos.com> wrote: > >> I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code

OK, I’ve hit one more existing regression test that I’m weary of: define void @test2_addrspacecast() { %A = alloca %T %B = alloca %T %a = addrspacecast %T* %A to i8 addrspace(1)* %b = addrspacecast %T* %B to i8 addrspace(1)* call void @llvm.memcpy.p1i8.p0i8.i64(i8 addrspace(1)* %a, i8* bitcast (%T* @G to i8*), i64 124, i32 4, i1 false) call void

The generic code in lib/CodeGen has no knowledge of these semantic differences. This knowledge is only available on a per-target basis. Typical query functions would be X86InstrInfo::getMemOpBaseRegImmOfs(...) or AArch64::getMemOpInfo(...). Doing this in a common way accross targets requires callbacks in TargetInstrInfo, there seem to be some in that direction but they appear to be rarely used so

So I'd like to be able to tell the difference between an imm and an imm used in mem offset in MachineInstr. Or, it would be nice to tell the difference between src and dst operands. I must be missing something trivial? For example, int *b, a; b[10] = a + 2; // is there any marker/flag between 2 and 10 to tell the difference? Thanks. -------------- next part -------------- An HTML

Hi Adam, John is right, the TCE stuff would be useful for you. Our compiler targets a processor template that the designer can populate pretty freely. The compiler then reads the architecture description and creates an LLVM backend on the fly. Please don't hesitate to get in touch with us if you have questions. -- Pertti

Hello gyus, I am working on a project, where we are trying to create a development environment for new ASIP processor design. Part of this project is a compiler generator, where we would like to generate C compiler from some instruction description. To keep it short, let's say, that in each instruction's semantics is described by some C code. What I would like to do is to compile this

Hi, I have added Branch condition BGEID like below… *def : Pat<(brcond (setcc (i32 GR32:$L), (i32 GR32:$R), SETGE), bb:$T),* * (BGEID (CMP GR32:$L, GR32:$R), bb:$T)>;* *def BGEID : TBT<0b101110, (outs), (ins GR32:$ra, brtarget:$offset), "bgeid\t$ra,$offset", [], IIC_BRc> {* * let rd = 0b10101;* *}* *def brtarget : Operand<OtherVT>* *{*

Add a specific optimisation pass for NV50 to check whether SRC0 or SRC1 is a MOV dst, IMM. If so: fold the IMM in and try to drop the MOV. Must be done post-RA because it is required that SDST == SSRC2. Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 52 ++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git

And you're allowing saturate/neg emission on the short form. Is this already in envytools? Also, what's the shortForm thing? This change is probably fine, but the changelog needs work. On Sat, Jan 10, 2015 at 7:22 PM, Roy Spliet <rspliet at eclipso.eu> wrote: > MAD IMM has a very specific SDST == SSRC2 requirement, so don't emit > > Signed-off-by: Roy Spliet <rspliet