similar to: RFC: Enforcing pointer type alignment in Clang

> On Jan 14, 2016, at 4:49 PM, Richard Smith <richard at metafoo.co.uk> wrote: > On Thu, Jan 14, 2016 at 12:56 PM, John McCall via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > C 6.3.2.3p7 (N1548) says: > A pointer to an object type may be converted to a pointer to a > different object type. If the resulting pointer is not

In practice all Apple hardwares support misaligned accesses for single-register loads and stores. If a pointer is not aligned, LLVM should not use the double-register loads and stores. It should keep the two single-register loads instead of trying to optimize them as one unsupported double-register load. Note that this code compiled with GCC 4.2 runs perfectly whereas LLVM will produce a binary

Hi John, On 15 Jan 2016, at 08:14, John McCall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The question at hand is whether we should require the user to write this: > misaligned_A_B *p = &a.b; > instead of, say: > A::B *p = &a.b; > int x = *(misaligned_int*) &p->n; > because we want to reserve the right to invoke undefined behavior and

Hi Hongbin, On 16 December 2016 at 12:22, Hongbin Zheng <etherzhhb at gmail.com> wrote: > Thanks for the explanation. The above code snippets is actually extracted by > bugpoint from MultiSource/Applications/ALAC/encode/alacconvert-encode.test. > I get a different result if I cast the pointer to int and mask away the > lower two bits and cast the int back to pointer. While

Understood for the aligned case, I want to measure performance degradation for unaligned case. I mean unaligned case versus aligned. I know this is stupid, but I want to try to pass a <4 x float>* as parameter of a routine and at the call site I want to pass a misaligned pointer. Since LLVM is generating movapd instruction it will raise an exception (SEGFAULT), I just want to know if there

What should a well behaved back end do with a load or store with alignment less than the natural alignment of the type? I believe C++ considers such access to be UB. I'm not sure what the IR semantics are. I think my options are: - Delete the operation / use undef - Lower as if it is naturally aligned - Lower via inefficient code that assumes align 1 Thanks, Jon -------------- next part

> I've seen the exact same in my version (mingw on win32), and the problem > was that the stack was misaligned when entering the function, so the temp > registers weren't at 16-byte boundries. That's a possibility. It's easy to check by printing the address of the variables. I know that gcc 3.3 had some alignment issues with _m128 that were supposed to be fixed in

Hi, I experienced a crash in code compiled with Clang 10.0.0 due to a misaligned 64-bit data access. The (ARMv8) CPU is configured with SCTL.A == 1 (alignment check enable). With SCTLR.A == 0 the code runs as expected. After some investigation I came up with the following reproducer: ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- $ cat test.c extern char

Related to this subject is the __attribute__(aligned(X)) that can be set on a type in C/C++. It is being used when generating the load / stores / memcpy / ... but is lost with respect to the type's attribute. In many a case this could help various analysis or transforms to provide more accurate results when such a type is used. The __builtin_assume_aligned could be an way to solve this.

Hi Tim, Thanks for the explanation. The above code snippets is actually extracted by bugpoint from MultiSource/Applications/ALAC/encode/alacconvert-encode.test. I get a different result if I cast the pointer to int and mask away the lower two bits and cast the int back to pointer. While casting pointer to int and back to pointer do not cause any problem. Thanks Hongbin On Fri, Dec 16, 2016 at

Jean-Marc Valin wrote: > Duane Storey a ?crit : >> Actually, it might just be an OS "feature".. On most linux and mac >> platforms, the memory managers align memory on proper boundaries -- this >> doesn't occur on most versions of windows. I don't have all the code in >> front of me, but it's possible that it's simply a side effect of windows

Hi all, Is there a way to force llc to generate movupd instruction instead of movapd for x86 target ? I know that movapd is more performant, but I would like to measure degradation when alignment constraints are not met. Best Regards Seb -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 03/25/2014 10:08 AM, Krzysztof Parzyszek wrote: > On 3/25/2014 8:53 AM, Frank Winter wrote: >> >> One can see that if the initial alignment of the pointee of %arg0 was 32 >> bytes and since the vectorizer operates on a loop with a fixed trip >> count of 4 and the size of double is 8 bytes, the vector loads and >> stores could be ideally aligned with 32 bytes

On Feb 28, 2011, at 2:58 AM, Sebastien DELDON-GNB wrote: > Understood for the aligned case, I want to measure performance degradation for unaligned case. > I mean unaligned case versus aligned. I know this is stupid, but I want to try to pass a <4 x float>* as parameter of a routine and at the call site I want to pass a misaligned pointer. Since LLVM is generating movapd instruction

On Nov 15, 2013, at 12:36 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 15 November 2013 20:24, Joshua Klontz <josh.klontz at gmail.com> wrote: > Agreed, is there a pass that will insert a runtime alignment check? Also, what's the easiest way to get at TargetTransformInfo::getRegisterBitWidth() so I don't have to hard code 32? Thanks! > > I think

Thorvald, re: At 03:18 AM 1/6/2006, Thorvald Natvig wrote: >I just checked it in the debugger, and this was with gcc 3.4.4 (mingw)... >And the addresses were not properly aligned :( From a bit of googling, >this seems to be a thread problem, as the gcc just maintains 16-byte >alignment of the stack -- if the start function of the thread had >misaligned stack, the misalignment

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

What is the proper solution to disable auto-vectorization for unaligned data? I have an out of tree target and I added this: bool OpusTargetLowering::allowsUnalignedMemoryAccesses(EVT VT, bool *Fast) const { if (VT.isVector()) return false; .... } After that, I could see that vectorization is still done on unaligned data except that llvm will copy the data back and forth from the source

Nadav, I believe aligned accesses to unaligned pointers is precisely the issue. Consider the function `add_u8S` before[1] and after[2] the loop vectorizer pass. There is no alignment assumption associated with %kernel_data prior to vectorization. I can't tell if it's the loop vectorizer or the codegen at fault, but the alignment assumption seems to sneak in somewhere. v/r, Josh [1]

A fix for this is in r194876. Thanks for reporting this! On Nov 15, 2013, at 3:49 PM, Joshua Klontz <josh.klontz at gmail.com> wrote: > Nadav, > > I believe aligned accesses to unaligned pointers is precisely the issue. Consider the function `add_u8S` before[1] and after[2] the loop vectorizer pass. There is no alignment assumption associated with %kernel_data prior to