similar to: How to get CLang array alloca alignments to be smaller than 16 bytes?

> 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

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 got me

Hi Tim I created an Xcode project with CMAKE, which should have the entire lot of files. Selecting the ‘install’ scheme Xcode compiles everything including all available targets for clang and llc, which then I can fully debug. So the Xcode project definitely has all the cpp files in it. However, I now have found that for some reason the .h files in the lib/Basic/Targets directory were not

To be honest, I don’t either know what really happens under the hood when CMake creates the xCode project for CLang+LLVM. But there’s something really explicit going on there, because the project as it’s shown in xCode does not have the same file grouping structure than the actual physical folders. Not only the project file grouping doesn't match the physical folder locations, but the group

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

Sorry Zach, my apologies. I understood now what you mean. I tried and it works!. But now I found that LLVM_DEBUG statements and other output to the console doesn’t show. How do I get that back?. Thanks John > On 4 Nov 2019, at 22:26, Zachary Turner <zturner at roblox.com> wrote: > > You hit Reply on my email but then addressed David. So I want to make sure you saw my

Hi Praveen, Thanks for the tip, but Xcode seems to spend all the time running tablegen "custom shell scripts", one by one at a time, not linking. Linking is actually very fast, possibly less than a second. The “scripts” that take longer are “AArch64CommonTableGen" and “AMDGPUCommonTableGen”. As said this is on LLVM 9.0. However, on LLVM 7.0.1, the same process takes just 5-6

If someone can manage it, it wouldn't be a bad thing - obviously open up more parallelism (I don't know how much of LLVM can be built before you hit everything that needs tblgen run - I guess libSupport and some other bits) On Mon, Jul 1, 2019 at 12:54 PM Zakharin, Vyacheslav P via llvm-dev < llvm-dev at lists.llvm.org> wrote: > [resending to the whole list] > > > >

Hey Joan, When looking for build support it is really useful to include a bunch of information about your build up front. Knowing that you are on macOS, and using the Xcode generator are really useful. On macOS, BUILD_SHARED_LIBS won’t really help much because the default linker (ld64) is pretty good. Using an IDE generator and setting LLVM_USE_OPTIMIZED_TABLEGEN will kill your release builds.

I had already adjusted MaxStoresPerMemcpy to my preferred value, and this works great but for the cases where load/stores are used on non-size aligned structs the odd behaviour still happens. For my 3-char, 3-byte struct test, the memcpy replacement appears to consist on a single byte load and store of the last char (this is correct), followed by a 16 bit move of the first two chars, this is also

Hi David, Thank you for your patience but I still don’t get it: I don’t see how that is a “command”, as it’s just a list of strings that state command options. I know how to use the debugger, this is what I attempt to debug: clang --target=msp430 -emit-llvm -c -S -Oz main.c The debugger works fine, but only on the main thread. However breakpoints do not work with the code that was invoked

Much of this has been discussed (over many, many years) on https://bugs.llvm.org/show_bug.cgi?id=28222 Some of the issues that were identified included: 1 - Poor tablegen dependency handling leading to unexpected rebuilds. 2 - Debug STL iterator checks taking an insane amount of time (might be MSVC specific). 3 - Lack of parallelization of custom commands (XCode and VS builds) - VS at least

I need to use ‘createVirtualRegister’ for a specific case in my ‘eliminateFrameIndex’ function implementation. However, whenever that code is executed, I get the assertion "MachineCopyPropagation should be run after register allocation!” at a later stage. I have seen that at least a couple of backend implementations (including ARM Thumb) create virtual registers in ‘eliminatedFrameIndex’.

Hi David, I understand what you say, but have you actually read my messages? I don’t think so, Anyway, I will repost the question in case someone else can help. Thanks John > On 4 Nov 2019, at 22:18, Zachary Turner <zturner at roblox.com> wrote: > > > > On Mon, Nov 4, 2019 at 1:11 PM Joan Lluch via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

This is also the case with the Visual Studio generators. Custom commands in a single cmake file essentially get written out line by line into a single batch file that gets processed as a custom build step. In the VS case this means that it can, for example, run X86 and Aarch64 tablegen steps in parallel with each other but all of the individual X86 invocations get processed serially. I can well

Hey Joan, Take a look at this patch, and see if it resolves your issue: https://reviews.llvm.org/D64300 <https://reviews.llvm.org/D64300> Thanks, -Chris > On Jul 7, 2019, at 3:54 PM, Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hey Joan, > > I looked into the Xcode build issue that you're experiencing, and it relates to a limitation in

I don’t personally develop on Mac (i use Windows), but I have an analogous setup there where i use ninja to build and Visual Studio for editing, debugging, etc. What i do, and I assume it will be the same or very similar for Xcode, is to run cmake twice, once with Ninja, and once with VS (Xcode for you), from separate directories. I build with the ninja one (“ninja clang” on command line), and I

Hi Praveen, Please, can you elaborate on this?. What do do mean by “building as shared objects”. Thanks, John > On 30 Jun 2019, at 07:32, Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > Maybe try building llvm as a shared objects.. > > On Jun 30, 2019 1:30 AM, "Joan Lluch via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at

Hi Joan, On Fri, 14 Jun 2019 at 11:45, Joan Lluch <joan.lluch at icloud.com> wrote: > When I started with this, I just downloaded the sources for the LLVM site, I did not even created a git for it. Then ran the CMAKE app (not from the command line) with the default settings other than also adding the ‘experimental’ targets, and boom a fully functional XCode project was created, so I gave

Hi David, Thank you for your help. Please, can you elaborate on this?. The command line that I get with -### starts with this: clang version 9.0.1 (https://github.com/llvm/llvm-project.git 6e38ee067b8fa08792f551fb565bbb8ada4864b1) Target: msp430 Thread model: posix InstalledDir: /Users/joan/LLVM-9/llvm-project/build/Debug/bin "/Users/joan/LLVM-9/llvm-project/build/Debug/bin/clang"