search for: widest

...: 0 LSR has identified the following interesting factors and types: *8 LSR is examining the following fixup sites: UserInst=%cmp11, OperandValToReplace=%i.010 UserInst=%0, OperandValToReplace=%arrayidx LSR found 2 uses: LSR is examining the following uses: LSR Use: Kind=ICmpZero, Offsets={0}, widest fixup type: i32 reg({0,+,-1}<nw><%while.body>) LSR Use: Kind=Address of i32 in addrspace(0), Offsets={0}, widest fixup type: i32* reg({@buffer,+,8}<nsw><%while.body>) After generating reuse formulae: LSR is examining the following uses: LSR Use: Kind=ICmpZero, O...

...ctors and types: *8 >> LSR is examining the following fixup sites: >> UserInst=%cmp11, OperandValToReplace=%i.010 >> UserInst=%0, OperandValToReplace=%arrayidx >> LSR found 2 uses: >> LSR is examining the following uses: >> LSR Use: Kind=ICmpZero, Offsets={0}, widest fixup type: i32 >> reg({0,+,-1}<nw><%while.body>) >> LSR Use: Kind=Address of i32 in addrspace(0), Offsets={0}, widest fixup type: >> i32* >> reg({@buffer,+,8}<nsw><%while.body>) >> >> After generating reuse formulae: >> LSR...

...xamining the following fixup sites: >>>> UserInst=%cmp11, OperandValToReplace=%i.010 >>>> UserInst=%0, OperandValToReplace=%arrayidx >>>> LSR found 2 uses: >>>> LSR is examining the following uses: >>>> LSR Use: Kind=ICmpZero, Offsets={0}, widest fixup type: i32 >>>> reg({0,+,-1}<nw><%while.body>) >>>> LSR Use: Kind=Address of i32 in addrspace(0), Offsets={0}, widest fixup >> type: >>>> i32* >>>> reg({@buffer,+,8}<nsw><%while.body>) >>>> >>&...

Hi Nadav/Devs I am exploring Loop Vectorizer to vectorize i8 scalar operations into 8xi8 vector operation. I was expecting the Loop Vectorizer to analyze the profitability for vectorization factor(VF) of 8, However it is not doing so due to the widest type calculation done for the blocks inside the loop. May be I am missing something, however, I am curious to know why Loop Vectorizer limits the profitability check to widest type and not allowing for other narrower type? Regards, Shahid -------------- next part -------------- An HTML attachment...

...that doubles every element in a vector. I've found that 'opt -loop-vectorize -force-vector-width=4 -S -debug double.ll' works as expected. However, removing the -force-vector-width flag results in no vectorization. From the debug output I can see that the issue boils down to: LV: The Widest type: 32 bits. LV: The Widest register is:32bits. I tried to work back through the source code to figure out why the widest register is incorrect, though I get lost following the code logic for how TargetTransformInfo gets initialized. Therefore, I have two questions: 1) Can -force-vector-width b...

...ailto:Asghar-ahmad.Shahid at amd.com>> wrote: Hi Nadav/Devs I am exploring Loop Vectorizer to vectorize i8 scalar operations into 8xi8 vector operation. I was expecting the Loop Vectorizer to analyze the profitability for vectorization factor(VF) of 8, However it is not doing so due to the widest type calculation done for the blocks inside the loop. May be I am missing something, however, I am curious to know why Loop Vectorizer limits the profitability check to widest type and not allowing for other narrower type? The vectorizer stops the search of profitable vectorization factors at the...

...r. > > I've found that 'opt -loop-vectorize -force-vector-width=4 -S -debug > double.ll' works as expected. However, removing the -force-vector-width > flag > results in no vectorization. From the debug output I can see that the issue > boils down to: > > LV: The Widest type: 32 bits. > LV: The Widest register is:32bits. > > I tried to work back through the source code to figure out why the widest > register is incorrect, though I get lost following the code logic for how > TargetTransformInfo gets initialized. Therefore, I have two questions: >...

...ctor. > > I've found that 'opt -loop-vectorize -force-vector-width=4 -S -debug > double.ll' works as expected. However, removing the -force-vector-width flag > results in no vectorization. From the debug output I can see that the issue > boils down to: > > LV: The Widest type: 32 bits. > LV: The Widest register is:32bits. > > I tried to work back through the source code to figure out why the widest > register is incorrect, though I get lost following the code logic for how > TargetTransformInfo gets initialized. Therefore, I have two questions: >...

...doesn't shine through. The debug output of the loop vectorizer says: LV: Checking a loop in "main" from module LV: Loop hints: force=? width=0 unroll=0 LV: Found a loop: L3 LV: Found an induction variable. LV: We can vectorize this loop! LV: Found trip count: 8 LV: The Smallest and Widest types: 32 / 32 bits. LV: The Widest register is: 32 bits. LV: Found an estimated cost of 0 for VF 1 For instruction: %6 = phi i64 [ %14, %L3 ], [ 0, %L5 ] LV: Found an estimated cost of 1 for VF 1 For instruction: %7 = add nsw i64 %19, %6 LV: Found an estimated cost of 0 for VF 1 For instruct...

I would need this to work when calling the vectorizer through the function pass manager. Unfortunately I am having the same problem there: LV: The Widest type: 32 bits. LV: The Widest register is: 32 bits. It's not picking the target information, although I tried with and without the target triple in the module. Any idea what could be wrong? Frank On 26/10/13 15:54, Hal Finkel wrote: > ----- Original Message ----- >>>>> LV...

...39;ve found that 'opt -loop-vectorize -force-vector-width=4 -S -debug >> double.ll' works as expected. However, removing the -force-vector-width flag >> results in no vectorization. From the debug output I can see that the issue >> boils down to: >> >> LV: The Widest type: 32 bits. >> LV: The Widest register is:32bits. >> >> I tried to work back through the source code to figure out why the widest >> register is incorrect, though I get lost following the code logic for how >> TargetTransformInfo gets initialized. Therefore, I have...

----- Original Message ----- > >>> LV: The Widest type: 32 bits. > >>> LV: The Widest register is: 32 bits. > > Yep, we don’t pick up the right TTI. > > Try -march=x86-64 (or leave it out) you already have this info in the > triple. > > Then it should work (does for me with your example below). That may depend...

...mber of columns and rows; I am able to put the sizer into a form and able to put controls into the FlexGrid control without any proble. However all the columns are the same width, and I can''t find any combination of flags that will make the the columns anything other than the width of the widest column. Most of the controls going into the grid are TextCtrls and I have specified the "maximum_size" attribute as a Size.new(x,-1) with the following flags: ALIGN_LEFT | ST_NO_AUTORESIZE. When adding the controls to the FlexGrid to "proportion" field is set to zero. And ye...

...&PM) { // Add first the target-independent BasicTTI pass, then our X86 pass. This // allows the X86 pass to delegate to the target independent layer when // appropriate. PM.add(createBasicTargetTransformInfoPass(this)); PM.add(createX86TargetTransformInfoPass(this)); } > LV: The Widest type: 32 bits. > LV: The Widest register is: 32 bits. This strongly looks like no target has added a target transform info pass so we default to NoTTI. But, it could also be that you don’t have the right sub target (in which case you need to set the right cpu, “-mcpu” in opt, when the target m...

...ent BasicTTI pass, then our X86 pass. This > // allows the X86 pass to delegate to the target independent layer when > // appropriate. > PM.add(createBasicTargetTransformInfoPass(this)); > PM.add(createX86TargetTransformInfoPass(this)); > } > > > >> LV: The Widest type: 32 bits. >> LV: The Widest register is: 32 bits. > This strongly looks like no target has added a target transform info pass so we default to NoTTI. > > But, it could also be that you don’t have the right sub target (in which case you need to set the right cpu, “-mcpu” in opt,...

Hello, Currently the loop vectorizer will, by default, not consider vectorization factors that would make it generate types that do not fit into the target platform's vector registers. That is, if the widest scalar type in the scalar loop is i64, and the platform's largest vector register is 256-bit wide, we will not consider a VF above 4. We have a command line option (-mllvm -vectorizer-maximize-bandwidth), that will choose VFs for consideration based on the narrowest scalar type instead of the...

xend uses rtl8139, and we want xl to be compatible with xm. Some older operating systems don''t have e1000 drivers, and we want widest compatibility rather than best performance (people who want good performance are best advised to use PV-on-HVM drivers). We''ll probably switch to a new default when switching to upstream qemu, in the Xen 4.2 release cycle. Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> dif...

Hi Michael,  Thank you for working on this. The loop vectorizer tries a bunch of different vectorization factors and stops at the widest word size mostly because of compile time concerns. On every vectorization factors that we check we have to scan all of the instructions in the loop and make multiple calls into TTI. If you decide to increase the VF enumeration space then you will linearly increase the compile time of the loop vecto...

>>> LV: The Widest type: 32 bits. >>> LV: The Widest register is: 32 bits. Yep, we don’t pick up the right TTI. Try -march=x86-64 (or leave it out) you already have this info in the triple. Then it should work (does for me with your example below). On Oct 26, 2013, at 2:16 PM, Frank Winter <fwinter a...

...%13, i32 >> %14 >> LV: We need to do 2 pointer comparisons. >> LV: We can perform a memory runtime check if needed. >> LV: We need a runtime memory check. >> LV: We can vectorize this loop (with a runtime bound check)! >> LV: Found trip count: 0 >> LV: The Widest type: 32 bits. >> LV: The Widest register is: 32 bits. >> LV: Found an estimated cost of 0 for VF 1 For instruction: %14 = >> phi >> i32 [ %21, %L0 ], [ %1, %entrypoint ] >> LV: Found an estimated cost of 0 for VF 1 For instruction: %15 = >> getelementptr flo...