similar to: [LLVMdev] Code ownership of AArch64

Hi all, We'd like to promote the AArch64 backend to being built by default. I know it's very soon after the initial upload, but we think the backend is in a good position and should be stable. We'd very much like to get it tested in more diverse environments provided by the buildbots, and are committed to cleaning up any fallout as soon as possible, or as a last resort reverting the

Hi all, Thanks to everyone's hard work over the last few months, the last child of the AArch64/ARM64 merge issue (http://llvm.org/PR19392) has just been resolved. So I think it's time to finish the job. I'd like to delete the AArch64 target and move ARM64 into its place: for now we'll accept both aarch64 and arm64 triples in all places, and they will all be redirected to the

Hi folks, As Tim pointed out, we recently had the opportunity to collect 64-bit benchmark performance data for GCC 4.9, AArch64 and ARM64 compilers on a real hardware. It is a cortex-a53 device. Due to proprietary reasons we cannot share the full hardware configuration. The preliminary results were shared at the hackers lab at EuroLLVM yesterday. For those who could not make it, below is

Hi Gerolf, Sorry for the delayed response. I had to get permission to share more details. I am allowed to share relative numbers but not absolute numbers. Any missing test is due to runtime failures (e.g., gcc failure due to the fused multiply pattern bug which Tim fixed later on). Thanks, Ana. Benchmarks ARM64 vs GCC 4.9 % ARM64 vs AArch64 % ARM64 vs AArch64 patched %

The point here is, if you are not building for Android. You will hit this patch with cmake configuration -DCOMPILER_RT_TEST_TRIPLE=aarch64-linux-gnu + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") + test_target_arch(aarch64 "-march=aarch64") I don't see "-march=aarch64" is a valid flag on either LLVM or GCC. Should we replace this

On 10 December 2014 at 16:06, Renato Golin <renato.golin at linaro.org> wrote: > Hi Sumanth, > > Christophe (cc'd) is seeing the same problems on his build. It seems > that r181130 (by Tim) has something to do with it, but I'm not sure. > > I remember trying to build compiler-rt on AArch64 natively in > February, and even running the test-suite with it, so

On Jan 31, 2013, at 4:37 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi all, > > We'd like to promote the AArch64 backend to being built by default. I > know it's very soon after the initial upload, but we think the backend > is in a good position and should be stable. > > We'd very much like to get it tested in more diverse environments >

Hi Paul, > I'm getting a "random" build failure related to AArch64 when building with cmake. > The build is running with -j32 so it seems that there is some dependency issue > that causes the build to fail when things build in a certain order. > 3008 make[2]: *** No rule to make target `lib/Target/AArch64/AArch64GenDAGISel.inc', needed by Hmm. That file's

On Fri, Sep 18, 2015 at 10:34 PM, Tim Northover <t.p.northover at gmail.com> wrote: > AArch64's fmadd instruction is fused, which means it can produce a > different result to the two operations executed separately. The C and > C++ standards do not allow such changes. Sorry, sloppy language on my part. I was aware of fmadd, but I was really asking about turning sequences like:

Hi, I'm getting a "random" build failure related to AArch64 when building with cmake. The build is running with -j32 so it seems that there is some dependency issue that causes the build to fail when things build in a certain order. Is anyone else seeing this problem? paul 3008 make[2]: *** No rule to make target `lib/Target/AArch64/AArch64GenDAGISel.inc', needed by

Hi, I’ve stumbled across something curious with the Relase_40 I have built here: I tried to build for aarch64-apple-iphoneos, but ended up getting ELF objects $ clang -target aarch64-apple-iphoneos -c tmp.ll -o tmp.o warning: overriding the module target triple with aarch64-apple-iphoneos [-Woverride-module] 1 warning generated. bin $ file tmp.o tmp.o: ELF 64-bit LSB relocatable, ARM aarch64,

Hi Tim, On 01/ 8/14 10:24 PM, Tim Northover wrote: > Hi Karel, > >> I've observed the same issue with LLVM 3.4 as distributed by Ubuntu 13.10 >> and with LLVM HEAD compiled on January 6. I'm able to provide the byte-code >> file which results in this issue, but would first like to know if this is a >> known issue in AArch64 target support or if I shall submit

Hi Tim, 2014-06-25 15:26 GMT+08:00 Tim Northover <t.p.northover at gmail.com>: > Hi Kevin, > > I assume you've looked at the GCC documentation in this area, since > your ideas are very similar: > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html. I actually > think that looks like a rational set of conventions too. > > The main difference appears to be

On 16 December 2014 at 21:12, Gundapaneni, Sumanth <sgundapa at quicinc.com> wrote: > The point here is, if you are not building for Android. > You will hit this patch with cmake configuration -DCOMPILER_RT_TEST_TRIPLE=aarch64-linux-gnu > > + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") > + test_target_arch(aarch64

Hi, Recently, I committed a patch adding default features for '-mcpu'. And after that, Eric replied me here's a proposal toward using '-march' instead of '-mcpu'. As it's half a year later from original proposal, some background may changes. One thing worth to mention is, during this time, Apple Contributed its backend and introduced another new CPU type: cyclone.

> I think this is the right thing to do. Once you've resolved the Mac and Windows issues, go for it. Thanks Doub. Just to let people know what happened. I enabled in r174322 around lunchtime. Here's a report of the noticed failures with status (important/outstanding ones at the top). Feel free to do anything from telling me about more problems to reverting the patch when llvm.org comes

Hi all, A bunch of us met at EuroLLVM to discuss the planned merge of the two current AArch64 backends in the tree. The primary question was which backend should form the basis of the merge (since the core .td files aren't directly mergeable), with code being cherry-picked from the other on a case-by-case basis. There were factors to consider both ways, but I think the key points of interest

Hi All, Recently I was doing some AArch64 work and noticed some cases where fmuls were not getting fused with fadds. Is there any particular reason that the AArch64 machine combiner doesn't do this like it does for add/mul? I am happy to work up a patch for this, but I wanted to make sure that there wasn't a good reason for it not already being there. FWIW, I see where GCC is doing

Hi Tim, There are three remaining broken tests on AArch64 on Gabor's buildbot: http://lab.llvm.org:8011/builders/llvm-aarch64-linux CodeGen/Generic/2011-07-07-ScheduleDAGCrash.ll ** LLVM ERROR: Can't handle live physical register dependency! CodeGen/Generic/asm-large-immediate.ll ** error: invalid operand in inline asm: '/* result: ${0:c} */'

On Sat, Nov 29, 2014 at 08:34:37PM +0100, Dimitry Andric wrote: > On 29 Nov 2014, at 02:48, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Nov 26, 2014 at 07:44:20PM +0100, Dimitry Andric wrote: > ... > >> I would like to propose the following additional patches for 3.5.1. These will already be part of the upcoming clang 3.5.0 import into the FreeBSD 11.0 base