search for: allowsmisalignedmemoryaccess

...eck if the data at positions 4, 16, 32 is aligned, but I cannot get a clear picture on the impact on performance (hence the side question below). Also, some preliminary alignment checks I added break some ARM tests (and not their AArch64 counterparts). The cause is getting "not fast" from allowsMisalignedMemoryAccesses, from checking hasV7Ops. I'd appreciate getting some guidance one how to best address and analyze this. Side question for Tim and other ARM folks, could I get a recommendation on reading material for performance tuning for the different ARM archs? Thank you, Alina -------------- next part -...

Hello, LLVM Devs. I'm compiling following code using my own backend: int foo() { char arr[4]; arr[0] = 0xAA; arr[1] = 0xBB; arr[2] = 0xCC; arr[3] = 0xDD; return *(int*)&arr[0]; } The memory operation in "return" statement ends up transformed into 4-byte load in the initial DAG: load<(dereferenceable load 4 from %ir.7, align 1, addrspace 1)> t31,

Hi Joan, On Mon, 13 May 2019 at 18:01, Joan Lluch <joan.lluch at icloud.com> wrote: > After looking at it a bit further, I think this is a Clang thing. Clang issues “align 2” if the struct has at least one int (2 bytes), but also if the entire struct size is multiple of 2. For example a struct with 4 char members. In these cases the LLVM backend correctly creates word sized load/stores

Hi John, On Tue, 14 May 2019 at 17:51, Joan Lluch <joan.lluch at icloud.com> wrote: > This problem is also shared by the MSP430 target, and it’s very easy to reproduce by just compiling the code that I posted before. That's some good detective work; it definitely explains what you're seeing. Since MSP430 is affected it would probably be pretty easy to upstream an alignment-aware

Hi Mats, It's private backend. I will try describing what I am dealing with. struct S { unsigned int a : 8; unsigned int b : 8; unsigned int c : 8; unsigned int d : 8; unsigned int e; } We want to read S->b for example. The size of struct S is 64 bits, and seems LLVM treats it as i64. Below is the IR corresponding to S->b, IIRC. %0 = load

...nce, but the vectoriser should be able > to pick that up from the cost analysis pass (2-way vs 4-way). > > > > Also, some preliminary alignment checks I added break some ARM tests (and > > not their AArch64 counterparts). The cause is getting "not fast" from > > allowsMisalignedMemoryAccesses, from checking hasV7Ops. > > What do you mean by "break"? Bad codegen? Slower code? > > > > Side question for Tim and other ARM folks, could I get a recommendation > on > > reading material for performance tuning for the different ARM archs? > > ARM has...