search for: largearrayminwidth

> Are you looking in Clang's source, and that from the same 7.0 version? Yes, I am, and it’s the same version (7.0.1). “LargeArrayMinWidth” is only on the following files: TargetInfo.cpp TargetInfo.h So I still think there’s something else that makes the difference on the x86 target. Anyway, I will now investigate other targets as my temporary frontend. It is right that other targets do not create such big alignments. Thanks for...

...ear in any searches. I suppose this can be reported as a bug of the Cmake configuration files for xCode. John > On 5 May 2019, at 22:01, Tim Northover <t.p.northover at gmail.com> wrote: > > On Sun, 5 May 2019 at 19:41, Joan Lluch <joan.lluch at icloud.com> wrote: >> “LargeArrayMinWidth” is only on the following files: >> >> TargetInfo.cpp >> TargetInfo.h > > OK, so I've downloaded the official Clang released source > (https://releases.llvm.org/7.0.0/cfe-7.0.0.src.tar.xz), and: > > $ tar xvf Downloads/cfe-7.0.0.src.tar.xz > [...] > $ c...

Hi Tim, I appreciate your reply, but I can’t still find any relation with “LargeArrayMinWidth” and x86 target. This variable is only in the TargetInfo.cpp and TargetInfo.h files and it’s not even in any x86 related file. I think there should be something else that causes my issue. I have my backend very advanced and already producing good assembly code, but this supposedly simple thing has...

I am working on a custom LLVM backend for a 16 bit architecture. For my architecture, I need smaller array alignments for arrays created on the stack. For example, consider the following code at the start of a C function: char localBuff[20]; char localBuff2[6]; this gets converted by Clang into this: %localBuff = alloca [20 x i8], align 16 %localBuff2 = alloca [6 x i8], align 1 Note

Hi, I'm seeing a bug in the AVR backend that seems to be caused by LLVM thinking things will be aligned to 8 bytes whereas they are unaligned. Specifically, MF->getDataLayout().getPrefTypeAlignment(Ty) returns 8 for the following two types: %opt = type { i8, [0 x i8], [3 x i8] } %Machine = type { i16, [0 x i8], i16, [0 x i8], [16 x i8], [0 x i8] } The target datalayout specifies that

On Mon, 22 May 2017, Krzysztof Parzyszek via llvm-dev wrote: > Probably from LargeArrayMinWidth/LargeArrayAlign settings in Targets.cpp (in > clang). Wait what? In clang? But my input is already LLVM IR. MF->getDataLayout().getPrefTypeAlignment(Ty) must be basing its answer on either something in the IR file, or in the target implementation, but clang is not really in the picture.

...argetInfo(Triple) { - LongWidth = LongAlign = PointerWidth = PointerAlign = 64; + const bool IsX32 = (getTriple().getEnvironment() == llvm::Triple::GNUX32); + LongWidth = LongAlign = PointerWidth = PointerAlign = IsX32 ? 32 : 64; LongDoubleWidth = 128; LongDoubleAlign = 128; LargeArrayMinWidth = 128; LargeArrayAlign = 128; SuitableAlign = 128; - IntMaxType = SignedLong; - UIntMaxType = UnsignedLong; - Int64Type = SignedLong; + if (IsX32) { + SizeType = UnsignedInt; + PtrDiffType = SignedInt; + IntPtrType = SignedInt; + } else { + IntMaxType =...

Hi, I'm working on bringing up complete coverage for a Gentoo x32 "desktop" system. I've been cooking up quite a few patches for various packages to push upstream, but right now, the biggest blocker is the lack of support for building with/codegen targeting x32 in llvm/clang. Since the x32 patches were sent last year, I see support code has landed in LLVM, and basic handling of

...argetInfo(Triple) { - LongWidth = LongAlign = PointerWidth = PointerAlign = 64; + const bool IsX32 = (getTriple().getEnvironment() == llvm::Triple::GNUX32); + LongWidth = LongAlign = PointerWidth = PointerAlign = IsX32 ? 32 : 64; LongDoubleWidth = 128; LongDoubleAlign = 128; LargeArrayMinWidth = 128; LargeArrayAlign = 128; SuitableAlign = 128; - IntMaxType = SignedLong; - UIntMaxType = UnsignedLong; - Int64Type = SignedLong; + if (IsX32) { + SizeType = UnsignedInt; + PtrDiffType = SignedInt; + IntPtrType = SignedInt; + } else { + IntMaxType =...