search for: underaligned

...nai at fb.com> Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Emitting aligned nlist_64 structures for Mach-O in MC I'd have figured if ld64 is able to handle this correctly (are you sure ld64 has UB in this situation when the lists are underaligned? perhaps it has utilities for doing underaligned reads, etc?) it's probably important for lld to handle them too - old object files in archives, things built by not-llvm, etc. On Tue, May 26, 2020 at 11:01 AM Shoaib Meenai via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists...

As part of our work on LLD for Mach-O, we’ve observed that the object files produced by LLVM don’t always have aligned nlist_64 entries. For context, nlist_64 is the 64-bit symbol table entry structure for Mach-O, and the symbol table is an array of nlist_64 entries. nlist_64 has an 8 byte member, so it should be 8-byte aligned, but we’ve seen object files where the symbol table only has a 4-byte

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

(Sorry for the duplicate mail, Richard, I accidentally sent a copy only to you before.) On Thu, Jan 14, 2016 at 10:26 PM, Richard Smith via cfe-dev < cfe-dev at lists.llvm.org> wrote: > [1]: That's not completely true, as it's possible to create an object > that is underaligned for its type: > > struct __attribute__((packed)) A { > char k; > struct B { int n; } b; > } a; > A::B *p = &a.b; // Misaligned pointer, now guaranteed OK > int main() { > int *q = &p->n; // UB? UBSan diagnoses this member access > return *q; // Obviousl...

> So, the pointer arguments of memcpy *shall* (a violation of a shall > clause is UB, per §4/2) have valid values, even though the function will > copy zero characters. This is true in C but the question was about LLVM intrinsics. Since the LangRef does not mention any such restriction, I would assume that memcpy(0,0,0) is not UB in LLVM. If it is UB then we must update the LangRef

As of earlier this year, we now explicitly ignore the nonnull attributes that glibc puts on memcpy (and other stdlib functions). I don't know how LLVM feels about dangling or underaligned pointers in particular, but AFAICT, we do try hard to make sure that memcpy(NULL, _, 0) works as the user probably intends. Here's the thread I read about it: http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html . As I recall, the tl;dr was "optimizing these assumptions to dea...

Hi All, I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics. (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy intrinsic. When set to '1' (the auto-upgrade default), this argument would indicate that the source and destination arguments may perfectly alias (otherwise they must not alias at all - memcpy prohibits partial overlap). While the C

> 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

I've run into a problem that I'm trying to figure out how to address and would welcome ideas and feedback. Today, the vectorizer will nicely vectorize loops using the widest legal vector type for the target. On a reasonable recent machine, this will often end up using AVX2 registers which are 32 bytes wide. If during register allocation, we decide to spill one of these registers, we