similar to: Reg units for unaddressable register parts?

On 9/28/2016 1:20 PM, Quentin Colombet wrote: > >> On Sep 28, 2016, at 10:52 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On X86, the registers AX, EAX and RAX all share the exact same register units. In terms of units, there is no difference between these registers. This makes register units insufficient to track liveness, since live AX

On 9/28/2016 7:30 PM, Quentin Colombet wrote: > Out of curiosity, could describe why this is useful to have such precision in the liveness tracking? RDF is meant to allow optimizations across the whole function. As a result, registers may change between basic blocks, and there is code to recalculate it. Accuracy is required to avoid unnecessary block live-ins. For example, calculate live-ins

On 9/28/2016 2:59 PM, Quentin Colombet wrote: > The cases where that it could make sense to use unaddressable register units are: > > 2. If we want to track precise liveness for physical registers > > #2 is not a problem IMO since most of our work with liveness happens on unallocated code. This is what I'm working on (RDF). I generate a data-flow graph for physical registers,

Ok, just to clarify, RegUnits, as far I understand, are Physical registers or alias to Physical registers. They exist because some instructions use physical registers directly rather than virtual register. It's right? And why this RegUnits should be present in the Interference Graph? I thought were only the Live Intervals would be the nodes of the graph. Sorry about the trouble to

Good Night. I'm implementing a Interference Graph in the Register Allocation pass. I'm building this graph BEFORE any assignment of a virtual register to physical register. But I have a doubt about how to check the interference between two Live Intervals (i.e. They live at same point), should I use: L1->overlaps(L2) Where L1 and L2 are two different Live Intervals. Or should I use:

After contacting Asus, MSI and Gigabyte, this is what I got back. Only motherboards with the QXX chipsets and certified with the Intel VPro support the Vt-d virtualization technology. I''m not sure about MSI though, because this is what I got from their support: "Almost board could support. Please refer to our website, http://www.msi.com/product/mb/." The problem is that

Hello - I found this post on the llvm blog: http://blog.llvm.org/2012/12/new-loop-vectorizer.html which makes me think that clang / llvm are capable of generating AVX with packed instructions as well as utilizing the full width of the YMM registers… I have an environment where icc generates these instructions (vmulps %ymm1, %ymm3, %ymm2 for example) but I can not get clang/llvm to generate such

Hi Frank, What does --debug-only=vectorize says? You may try to get the datalayout and the triple on the IR header, just to make sure you got everything right. LLVM will honour those, and front-ends should create them correctly. --renato On 1 July 2015 at 19:06, Frank Winter <fwinter at jlab.org> wrote: > I realized that the function parameters had no alignment attributes on them.

Frank, It sounds like the SLP vectorizer thinks that it is more profitable to use 128bit wide operations (because 256bit operations are double pumped on Sandybridge). Did you see a different result on Haswell? Thanks, Nadav > On Jul 1, 2015, at 11:06 AM, Frank Winter <fwinter at jlab.org> wrote: > > I realized that the function parameters had no alignment attributes on them.

It probably does not pick the right processor architecture. You could try “clang -mavx” or “clang -march=corei7-avx” for ivy-bridge and “clang -march=core-avx2” or “clang -mavx2" for haswell. $ clang -march=core-avx2 -O3 -S -o - test.c .section __TEXT,__text,regular,pure_instructions .globl _f .align 4, 0x90 _f: ## @f

LLVM can model some quite complicated register banks now, and we even use registers to model some encoding constraints. For example, a few ARM instructions like strexd have two register operands that must be an aligned pair of consecutive GPR registers (like r0, r1). This constraint is modeled with the GPRPair register class containing R0_R1, R2_R3, ... pseudo-registers. Sometimes ISAs also

I'm working on the post-regalloc dataflow engine I mentioned yesterday. Currently I only need to track register operands. A MachineOperand has both a getReg() and a getSubReg() interface. For a physical register operand, is getReg() guaranteed to be the "most super" register with getSubReg() providing the specific subregister information for the operand? If so then for my current

I seem to have problem to get the SLP vectorizer to make use of the full 8 floats available in a SIMD vector on a Sandy Bridge CPU with AVX. The function is attached, the CPU flags are: flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> A MachineOperand has both a getReg() and a getSubReg() interface. >> For a physical register operand, is getReg() guaranteed to be the >> "most super" register with getSubReg() providing the specific >> subregister information for the operand? If so then for my current >> purposes it seems I

Hi All. This is an RFC for a proposed target specific X86 optimization for reducing code size in the encoding of AVX-512 instructions when possible. When the AVX512F instruction set was introduced in X86 it included additional 32 registers of 512bit size each ZMM0 - ZMM31, as well as additional 16 XMM registers XMM16-XMM31 and 16 YMM registers YMM16-YMM31. In order to encode the new registers of

Hi, What is the calling conventions for YMM. According to documents I saw till now, the YMMs are scratch and not saved in callee. This is also the default behavior of the Intel Compiler. In X86InstrControl.td the YMMs are not in "defs" set of call. - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments

I'll explain what we see in the code. 1. The caller saves XMM registers across the call if needed (according to DEFS definition). YMMs are not in the set, so caller does not take care. 2. The callee preserves XMMs but works with YMMs and clobbering them. 3. So after the call, the upper part of YMM is gone. - Elena -----Original Message----- From: Bruno Cardoso Lopes [mailto:bruno.cardoso at

On Jan 9, 2012, at 10:00 AM, Jakob Stoklund Olesen wrote: > > On Jan 8, 2012, at 11:18 PM, Demikhovsky, Elena wrote: > >> I'll explain what we see in the code. >> 1. The caller saves XMM registers across the call if needed (according to DEFS definition). >> YMMs are not in the set, so caller does not take care. > > This is not how the register allocator

Hi all, I'm interested in fixing PR14481 (http://llvm.org/PR14481), regarding teaching LLVM that coldcc functions do not clobber any registers. As a brief motivation why: this can have a significant performance benefits and is very useful for instrumenting code with many calls that are executed only very rarely. Ubsan's runtime calls are a good example of this. Attached is my attempt

Hi, > What is the calling conventions for YMM. According to documents I saw till now, the YMMs are scratch and not saved in callee. > This is also the default behavior of the Intel Compiler. x86_64 Non-windows targets use the rules defined in the x86_64 abi! > In X86InstrControl.td the YMMs are not in "defs" set of call. The XMMs are subregisters of YMMs, and they are in the