similar to: [LLVMdev] Extending Vector GEP - proposal

> This problem can be solved by sinking the broadcast instruction at codegen-prepare time. I considered this option. We currently don’t have target specific optimizations in codegen-prepare time. (Or I’m wrong?) And it will be very X86-directed optimization. Even gather-scatter intrinsics are considered as common for all targets. And the second reason, why I’d prefer to generate a splat-GEP,

I tried to retrieve anything from DataLayout. It contains pointer size, but how can I conclude that the GEP index can't be widened? - Elena From: Hal Finkel [mailto:hfinkel at anl.gov] Sent: Monday, January 15, 2018 20:34 To: Demikhovsky, Elena <elena.demikhovsky at intel.com>; llvm-dev at lists.llvm.org; Sanjay Patel (spatel at rotateright.com) <spatel at

On 01/15/2018 12:59 PM, Demikhovsky, Elena wrote: > > I tried to retrieve anything from DataLayout. It contains pointer > size, but how can I conclude that the GEP index can’t be widened? > I meant that we'd add a new field giving the preferred size for indexing arithmetic.  On the other hand, in your case, and in general, would it make sense to prevent widening beyond the largest

Hi all, I'm working on an out-of-tree target and encountered the following problem: InstCombiner "normalizes" GEPs and extends Index operand to the Pointer width. It works fine if you can convert pointer to integer for address calculation and I assume that all registered targets do this. The target I'm working on has very restricted ISA for the

On 01/15/2018 12:21 PM, Demikhovsky, Elena wrote: > Hi all, >   > I’m working on an out-of-tree target and encountered the following > problem: >   > InstCombiner “normalizes” GEPs and extends Index operand to the > Pointer width. > It works fine if you can convert pointer to integer for address > calculation and I assume that all registered targets do this. >   >

> On 15 Jan 2018, at 18:21, Demikhovsky, Elena via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I’m working on an out-of-tree target and encountered the following problem: > > InstCombiner “normalizes” GEPs and extends Index operand to the Pointer width. > It works fine if you can convert pointer to integer for address calculation and I assume

Hi, We have a function in IRBuilder.h Value *CreateVectorSplat(unsigned NumElts, Value *V, const Twine &Name = "") { .. } This function creates 2 instructions - "insertelement" and "shuffle" with all-zero mask. Now I want to add Value *getSplatValue(Value *Val). This function will try to recognize the pattern - insertelement+shuffle and return the splat value

> Note that InstCombine is not the only place that tries to insert pointer-width GEPs in the optimization pipeline. I think that we’ve fixed all of them, but I can’t be entirely sure. I'm going to upload a patch, but I'm fixing only the places that are covered by our test system. I'll add you as a reviewer and you are welcome to help me with fixing them all. > We haven’t

Hi, I check-out the latest version of LLVM and see many failures (on Win64): ******************** 67> FAIL: LLVM :: Transforms/GlobalOpt/zeroinitializer-gep-load.ll (5518 of 7763) 67> ******************** TEST 'LLVM :: Transforms/GlobalOpt/zeroinitializer-gep-load.ll' FAILED ******************** 67> Script: 67> -- 67> W:/LLVM_org/build64/bin/Debug/opt.EXE <

----- Original Message ----- > From: "Ayal Zaks" <ayal.zaks at intel.com> > To: "Philip Reames" <listmail at philipreames.com>, dag at cray.com, "Elena Demikhovsky" <elena.demikhovsky at intel.com> > Cc: "Robert Khasanov" <robert.khasanov at intel.com>, llvmdev at cs.uiuc.edu > Sent: Monday, December 22, 2014 8:05:43 AM

----- Original Message ----- > From: "Elena Demikhovsky" <elena.demikhovsky at intel.com> > To: "Hal J. Finkel" <hfinkel at anl.gov>, "Eli Friedman" > <eli.friedman at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Richard Smith" > <richard-llvm at metafoo.co.uk> > Sent: Tuesday, July 26,

On 12/18/2014 11:56 AM, dag at cray.com wrote: > "Demikhovsky, Elena" <elena.demikhovsky at intel.com> writes: > >> Semantics: >> For i=0,1,…,N-1: if (Mask[i]) {*(BaseAddr + VectorOfIndices[i]*Scale) >> = VectorValue[i];} >> VectorValue: any float or integer vector type. >> BaseAddr: a pointer; may be zero if full address is placed in the

> On Jul 25, 2016, at 10:16 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > From: "Elena via llvm-dev Demikhovsky" <llvm-dev at lists.llvm.org> > To: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, July 25, 2016 9:45:55 AM > Subject: [llvm-dev] Alias Analysis with inbound GEPs > > Hi, > > I’m

----- Original Message ----- > From: "Xinmin Tian" <xinmin.tian at intel.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Ayal Zaks" <ayal.zaks at intel.com> > Cc: dag at cray.com, "Robert Khasanov" <robert.khasanov at intel.com>, llvmdev at cs.uiuc.edu > Sent: Tuesday, December 23, 2014 7:36:44 PM > Subject: RE:

Sent from my Verizon Wireless 4G LTE DROID On Jul 25, 2016 6:10 PM, Eli Friedman <eli.friedman at gmail.com<mailto:eli.friedman at gmail.com>> wrote: > > On Mon, Jul 25, 2016 at 2:06 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: >> >> >> ________________________________ >>> >>>

In a debug build you should get a stack trace by default, which would be helpful here. I can try to repro later today, but I'm not surprised there are issues because most people I know stick with 32-bit builds even on 64-bit Windows. On Mon, Apr 29, 2013 at 4:27 AM, Demikhovsky, Elena <elena.demikhovsky at intel.com> wrote: > Hi, > > > > I check-out the latest version of

I’m checking aliasing of two pointers: %GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 1, i64 %indvars.iv41, i64 %indvars.iv39 %GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 16 The result I got is “PartialAlias” because the indices of the GEP1 are variable. That seems like a bug. PartialAlias should only be returned when we can prove a partial

I fell over this issue yesterday myself with lots of asserts being thrown. I think the issue is in lib/IR/AsmWriter.cpp:1618 in the function AssemblyWriter::printFunction(const Function *F) Looking at the code I think the 2nd for loop should be preceded by the test ... if (Idx < AS.getNumSlots()) Not sure why it doesn't fail on other platforms as it looks like it should be a genuine

Hi, I'm checking aliasing of two pointers: %GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 1, i64 %indvars.iv41, i64 %indvars.iv39 %GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 16 The result I got is "PartialAlias" because the indices of the GEP1 are variable. Shouldn't the "inbounds" keyword mean that the access to

If I'm understanding correctly, you're saying that vgather* is slow on all of Excavator, Haswell, Broadwell, and Skylake (client). Therefore, we will not generate it for any of those machines. Even if that's true, we should not define "gatherIsSlow()" as "hasAVX2() && !hasAVX512()". It could break for some hypothetical future processor that manages to