similar to: Semantics for non-byte-sized stores? (or whenever "store size in bits" is different than "size in bits")

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

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

If I run: opt -globals-aa -die -inline -debug-pass=Details foo.ll -S then I will get this pass structure: Target Library Information Target Transform Information Target Pass Configuration Assumption Cache Tracker Profile summary info ModulePass Manager CallGraph Construction Globals Alias Analysis FunctionPass Manager BasicBlockPass Manager Dead Instruction

I'm not sure about the old pass manager, but I think the new pass manager solves this issue. See llvm::updateCGAndAnalysisManagerForFunctionPass where it updates the call graph to be in sync with edges deleted by function passes. So I suspect the right fix is to use the new pass manager. -- Sanjoy On Mon, May 7, 2018 at 7:32 AM, Björn Pettersson A via llvm-dev <llvm-dev at

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

> Why? I'd prefer we avoid introducing even more special cases. Is there > any reason why we should not define "complex <scalar type>", or to be > more restrictive, "complex <floating-point type>"? I really don't like > the idea of excluding 128-bit complex types, and I think that we can > have a generic facility. Hal, we had 128-bit

On 9/27/19 7:33 AM, Matt Arsenault via llvm-dev wrote: > > >> On Sep 27, 2019, at 09:07, Björn Pettersson A via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Obviously we do not store into two locations (it is still a single >> two byte store). >> So is it (always) correct to interpret the list of

Hi, In llvm/test/Transforms/InstCombine/cast.ll there is a test like this: target datalayout = "E-p:64:64:64-p1:32:32:32-p2:64:64:64-p3:64:64:64- a0:0:8-f32:32:32-f64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64- v64:64:64-v128:128:128-n8:16:32:64" [...] define <3 x i32> @test60(<4 x i32> %call4) { ; CHECK-LABEL: @test60( ; CHECK-NEXT: [[P10:%.*]] = shufflevector

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

Hello: When I use SPSS I execute the AGGREGATE DATA comand for the next data: 2112141123212213212213334 3143244113442312121213344 2114141123112214212113344 2112211122212413421213221 3114444123442414343413344 2312231223212222323223322 2143241123212313131213234 2113241113212313222213333 2113141123112214212113344 2114141123412111114413344 2113211122342314222313234 2114141123112414212113344

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

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

> On Feb 12, 2019, at 4:02 AM, Björn Pettersson A via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > (Sorry if this subject already has been discussed, but I could not find any clear rules/recommendations.) > > What would the recommendation be for acronyms (I’ve seen the rule about avoiding them unless they are “well known”, > but sometimes an acronym is useful, and we

Hi, I have, in postres, a piece of IR that, after inlining and constant propagation boils (when cooked on really high heat) down to (also attached for your convenience): source_filename = "pg" target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-linux-gnu" define void @evalexpr_0_0(i8* align 8 noalias, i32* align 8 noalias) {

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

In https://bugs.llvm.org/show_bug.cgi?id=38011 (see also https://reviews.llvm.org/D48721) a problem was revealed related to llvm.loop metadata. The fault was that clang added the !llvm.loop metadata to branches outside of the loop (not only the loop latch). That was not handled properly by some opt passes (simplifying cfg) since it ended up merging branch instructions with different !llvm.loop

Hi all, hope someone can help me out with this. Background Introduction I have a data set consisting of data collected from a questionnaire that I wish to validate. I have chosen to use confirmatory factor analysis to analyse this data set. Instrument The instrument consists of 11 subscales. There is a total of 68 items in the 11 subscales. Each item is scored on an integer scale between 1 to 4.

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

So what is the status about LiveVariables. Is there a plan to remove it? After searching in old lvm-dev-mails it is mentioned that LiveVariable still exists due to one pass needing it. And a comment in TargetPassConfig.cpp indicates that the pass in question is TwoAddressInstruction: // FIXME: Once TwoAddressInstruction pass no longer uses kill flags, // LiveVariables can be removed