similar to: X32 bugs around "cannot select" lingering around

Hi Pavel, We (the Native Client team) are also interested in helping you get these reviewed and in, especially the x86 backend stuff. Native Client's x86-64 ABI is similar to x32 so we could probably share a good portion of the code if it's structured the right way. -Derek On 1404316081542, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Wed, Jul 2, 2014 at 3:59 PM, Pavel

Hi all, We (Intel) would like to revive this thread on X32 ABI support upstreaming. X32 ABI homepage is here: https://sites.google.com/site/x32abi/ Currently x32 support is available in kernel/glibc/gcc/binutils and one can install for example Ubuntu 14 with extra x32 lib packages (apt-get install libc6-dev-x32) to evaluate x32-target code generated by GCC (gcc supports x32 on Ubuntu 14 out of

X32 support patch for compiler-rt. Applies against current trunk. --- projects/compiler-rt/make/platform/clang_linux.mk~ 2013-08-21 06:27:38.000000000 +0000 +++ projects/compiler-rt/make/platform/clang_linux.mk 2013-08-21 11:16:55.891621025 +0000 @@ -41,7 +41,18 @@ SupportedArches += x86_64 endif else - SupportedArches := x86_64 + # x86-64 arch has two ABIs 64 bit x86-64 and 32 bit

Clang patch for X32 support. Applies against current trunk. --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6 backward compatibility">; def m3dnowa : Flag<["-"], "m3dnowa">,

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

Ah, I've replied in a different thread already. What Dmitri says - If you're interesting in only building the Clang on x32 host, you may avoid checking out compiler-rt repo for now. On Thu, Aug 22, 2013 at 10:59 AM, Dmitri Gribenko <gribozavr at gmail.com>wrote: > On Wed, Aug 21, 2013 at 11:04 PM, Steven Newbury <steve at snewbury.org.uk> > wrote: > > I've

Hi Steven, This looks interesting and raises a number of questions :) 1) Does applying this patch actually bring working sanitizers to x32 platform? That is, after you build the clang, does "clang -fsanitize=whatever foo.c" compile/link/run with expected results? I doubt that, as there is some platform-specific code in all the sanitizers, and many of them heavily depend on the address

On Thu, 2013-08-22 at 11:29 +0400, Alexey Samsonov wrote: > Ah, I've replied in a different thread already. What Dmitri says - If > you're interesting in only building the Clang on x32 host, you may avoid > checking out compiler-rt repo for now. > > compiler-rt does make a convenient compiler test though.. :) fatal error: error in backend: Cannot select: 0x30ccf38: ch =

Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the

If you are interesting to play around X32, you may refer to http://sourceware.org/glibc/wiki/x32 to bootstrap a local environment on Linux. Yours - Michael -----Original Message----- From: cfe-commits-bounces at cs.uiuc.edu [mailto:cfe-commits-bounces at cs.uiuc.edu] On Behalf Of Liao, Michael Sent: Monday, June 04, 2012 5:09 PM To: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu

This patch is still not creating elf32_x86_64 objects. No idea why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 hosts which is nice. :) --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6

Hi All, The 2020 Virtual LLVM Developer's Meeting is coming up the week after next. I'll be hosting a JIT Birds-of-a-Feather session on Thursday the 8th at 10:55am PDT (See http://llvm.org/devmtg/2020-09/schedule/). I'm planning to run this more like a Round Table: Minimal introduction, plenty of time for discussion. Does anyone have any LLVM JIT related topics that they would

Hi Andres, A topic that I'd find interesting is what it'd take to make it easier to > use profile guided optimization in the context of JIT. A few years back > I crudely hacked this together, but it was fairly ugly. It'd be nice to > make that easier. Possibly too complicated for that type of session? We couldn't go into detail, but we could kick off a discussion and

Hi, I would like to discuss the future/potential use-cases of LLVM JIT. I'm also interested in reducing the compilation time of code in JIT component independent of static compiler. Is it sounds interesting? :) On Sat, 26 Sep 2020 at 07:49, Andres Freund <andres at anarazel.de> wrote: > Hi, > > On 2020-09-25 19:05:42 -0700, Lang Hames wrote: > > The 2020 Virtual LLVM

Seems that adding -extra-vectorizer-passes doesn't help to vectorizer in my case. LoopRotation re-run does nothing. 2014-10-15 2:54 GMT+04:00 Chandler Carruth <chandlerc at google.com>: > > On Tue, Oct 14, 2014 at 3:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> > I have and will continue to push >> > back on trying to add it until we at least

Hi Andres, Postgres uses removable code support and Orcv1. I does make me quite > worried to see a phase where there'll be no viable way of using both in > llvm. Why isn't the right answer here to at lest develop the > replacement as a set of patches / as a branch that then can be merged as > a whole / shortly after each other, rather than just starting to develop > a

Thanks for the tip - getting closer: $ ./capi_test 5 6 args[0]: 5 args[1]: 6 result: 4294959200 Here's the code I changed: printf("args[0]: %d\n", (int)LLVMGenericValueToInt(args[0], 0)); printf("args[1]: %d\n", (int)LLVMGenericValueToInt(args[1], 0)); uint64_t (*func)(); func = (uint64_t (*)())LLVMGetFunctionAddress(engine, "sum");

Hi Robert, Can you ping the code owners about these patches. It might be good to write a separate email per code owner and cc the appropriate -commits list. Thanks, Tom On Wed, Apr 02, 2014 at 06:16:44PM +0400, Robert Khasanov wrote: > Hi Tom, > > I would like to nominate the following patches to be backported to 3.4.1 > > Clang: > 1. r204742 - Zinovy Nis <zinovy.nis at

In order to vectorize code like this LLVM needs to prove that “A[i*7]” does not wrap in the address space. It fails to do so and so LLVM doesn’t vectorize this loop even if we try to force it. The following loop will be vectorized if we force it: int foo(int * A, int * B, int n, int k) { for (int i = 0; i < 1024; ++i) A[i] += B[i*k]; } So will this loop: int foo(int * restrict A, int

Hi Geoff, Importing symbols into the JIT from an object file or static library...? Sure! Are you interested in doing this with the C API, LLJIT, or raw OrcV2 components? The high-level answer here (which we can dig into further in the BoF) is: For object files: - For raw OrcV2 components you'll want to create an RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add'