similar to: What should a truncating store do?

So what is the correct behavior of the store <2 x i2>. Storing two bytes with a zext:ed i2 in each, or a bit packed vector? I can't remember any documentation mentioning that vectors are bit packed. But if LLVM is supposed to bit pack vectors, should we do it for any element size, or only when element size is less than the byte size, or only for i1 vectors? Maybe bit packing should be

(Not sure if this exactly maps to “truncating store”, but I think it at least touches some of the subjects discussed in this thread) Our out-of-tree-target need several patches to get things working correctly for us. We have introduced i24 and i40 types in ValueTypes/MachineValueTypes (in addition to the normal pow-of-2 types). And we have vectors of those (v2i40, v4i40). And the byte size in our

On 9/25/2017 9:14 AM, Björn Pettersson A wrote: > > (Not sure if this exactly maps to “truncating store”, but I think it > at least touches some of the subjects discussed in this thread) > > Our out-of-tree-target need several patches to get things working > correctly for us. > > We have introduced i24 and i40 types in ValueTypes/MachineValueTypes > (in addition to

They are starting to look complicated. The patch linked is interesting, perhaps v1 vectors are special cased. It shouldn't be too onerous to work out what one or two in tree back ends do by experimentation. Thanks again, it's great to have context beyond the source. On Fri, Sep 15, 2017 at 9:41 PM, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 9/15/2017 12:10 PM, Jon

OK, I'm clear on scalars. Data races are thankfully OK in this context. Densely packing vectors sounds efficient and is clear in the case where lanes * width is a multiple of 8 bits. I don't think I understand how it works in other cases. If we could take store <4 x i8> truncating to <4 x i7> as an example. This can be converted into four scalar i8 -> i7 stores with

It is possible to ask DataLayout about getTypeSizeInBits and also getTypeStoreSize. And there is a table showing an example of what it could look like: /// Size examples: /// /// Type SizeInBits StoreSizeInBits AllocSizeInBits[*] /// ---- ---------- --------------- --------------- /// i1 1 8 8 /// i8 8 8

For example, truncating store of an i32 to i6. My assumption was that this should write the low six bits of the i32 to somewhere in memory. Should the top 24 bits of a corresponding 32 bit region of memory be unchanged, zero, undefined? Should the two bits that would round the i6 up to a byte be preserved, zero, undefined? I can't write six bits directly so am trying to determine what set

On 9/15/2017 5:49 AM, Jon Chesterfield via llvm-dev wrote: > For example, truncating store of an i32 to i6. My assumption was that > this should write the low six bits of the i32 to somewhere in memory. > > Should the top 24 bits of a corresponding 32 bit region of memory be > unchanged, zero,  undefined? Unchanged. > Should the two bits that would round the i6 up to a byte

On 09/15/2017 10:55 AM, Friedman, Eli via llvm-dev wrote: > On 9/15/2017 5:49 AM, Jon Chesterfield via llvm-dev wrote: >> For example, truncating store of an i32 to i6. My assumption was that this should write the low six bits of the i32 to somewhere in memory. >> >> Should the top 24 bits of a corresponding 32 bit region of memory be unchanged, zero, undefined? > >

Hi Björn, 1) The pass pipeline syntax is documented here: https://github.com/llvm-project/llvm/blob/master/include/llvm/Passes/PassBuilder.h#L378 -die is not implemented, since the new pass manager does not support BasicBlock passes. But you can use dce instead: "-passes=dce" 2) I don't have a qualified answer here, but if I recall correctly, the trouble to correctly update the

Well, do you have a patch that enables the new pass manager that we can land then? To be more serious: 1) I don't even know how to run those passes using the new pass manager even if it where enabled by default. I guess that I'm supposed to use -passes. Is there a syntax description for that option somewhere? How do I for example run -die? 2) "Use the new pass manager" does

Thanks Bjorn! But The problem is still there. On Wed, Aug 8, 2018 at 2:04 AM, Björn Pettersson A < bjorn.a.pettersson at ericsson.com> wrote: > It looks quite dangerous to erase the instruction I inside the loop when > iterating over all instructions in the function. > I guess it depends on how the range based iterator is implemented if that > works or not. > > I think

I added one attribute named EndLine in LLVM IR before. LLVM's part is not hard, but will modify many places in Clang. I success for it, you can try this way. At 2018-04-12 16:53:21, "Björn Pettersson A" <bjorn.a.pettersson at ericsson.com> wrote: >What happened with this? Is there something for review in Phabricator? Or was this put-on-hold/forgotten? > >I also have

Many thanks for the pointer! I missed that bug report since the title was about GVN. If there's interest in supporting this feature I can help since we've formalized most of BasicAA. I can easily verify if proposed changes are correct. (I'll release the code soon). Nuno Quoting Björn Pettersson A <bjorn.a.pettersson at ericsson.com>: > Hi Nuno. > I can't

Björn Pettersson A <bjorn.a.pettersson at ericsson.com> writes: > In llvm (split) we have: > > UL4->UL3->UL2->UL1->UL0 > \ > ...->DL2->DL1 > > In clang (split) we have: > > UC4->UC3->UC2->UC1->UC0 > \ > ...->DC2->DC1 > > > DL1 is a commit that updates the

On Oct 8, 2007, at 12:47 PM, Duncan Sands wrote: > Hi Evan, thanks for replying. > >>> Now that I'm working on codegen support for arbitrary precision >>> integers (think i36 or i129), I've hit the problem of what >>> getTypeSize and friends should return for such integers (the >>> current implementations seem to me to be wrong). However it's

Hi. Thanks. I changed the code but the problem exists. This is my new code which is again very simple: ... bool runOnFunction(Function &F) override { vector<Instruction *> dels; dels.clear(); for (inst_iterator It = inst_begin(&F), Ie = inst_end(&F); It != Ie;) { Instruction *I = &*(It++); if (auto* op = dyn_cast<BinaryOperator>(I)) { IRBuilder<NoFolder>

Thank you again Eli, I would like to know if it's not better to use DependenceAnalysis to know which instruction depends on others… I'm running this pass on a simple example: … while.body: ; preds = %while.cond %1 = load i32, i32* %y, align 4 ← I1 %2 = load i32, i32* %y, align 4 %mul = mul nsw i32 %1, %2 ← I2 store i32 %mul, i32* %z, align 4

> -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: den 13 juli 2017 16:01 > To: Björn Pettersson A <bjorn.a.pettersson at ericsson.com>; David Chisnall > <David.Chisnall at cl.cam.ac.uk>; Dylan McKay <me at dylanmckay.io> > Cc: llvm-dev at lists.llvm.org; Carl Peto <carl.peto at me.com> > Subject: Re: [llvm-dev] RFC:

Hi Evan, thanks for replying. > > Now that I'm working on codegen support for arbitrary precision > > integers (think i36 or i129), I've hit the problem of what > > getTypeSize and friends should return for such integers (the > > current implementations seem to me to be wrong). However it's > > not clear to me how getTypeSize and friends are defined.