similar to: [LLVMdev] Request for Help: Teach ARM target to auto-detect cpu / subtarget features

On 11/05/12 04:56, 陳韋任 wrote: >> I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. >> >> What motivated this? Well this: >> http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM >> >> I believe one of the reason the benchmark numbers are totally

> I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. > > What motivated this? Well this: > http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM > > I believe one of the reason the benchmark numbers are totally bogus is that the compilation are done on ARM hosts.

On May 11, 2012, at 12:25 AM, James Molloy wrote: > On 11/05/12 04:56, 陳韋任 wrote: >>> I've just filed PR12794: Add ARM cpu / subtarget features auto-detection. And I would very much appreciate the community's help to implement this. >>> >>> What motivated this? Well this: >>> http://www.phoronix.com/scan.php?page=news_item&px=MTA5OTM

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

Hi Jim, The diff below is not intended to be a patch, but a starting point. It is the shortest path (I hope) to getting LLVM to emit ARM mapping symbols to the ELF without changing any shared interfaces. Could you have a look at the FIXME comments and offer some pointers on how to get this code out of MCELFStreamer? Thanks, Greg diff --git a/lib/MC/MCELFStreamer.cpp b/lib/MC/MCELFStreamer.cpp

As part of my ELLCC project (http://ellcc.org), I build clang/LLVM on my native x86_64 Linux box and then use it to compile itself. For further sanity checking, I then use that copy to cross compile for other targets (arm, armeb, i386, microblaze, mips, mipsel, ppc, and x86_64). After updating to a recent TOT revision, r195452, I get a strange error when cross compiling for the i386:

> ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.cpp > ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.sh > ecc: note: diagnostic msg: > > ******************** > The error only occurs for i386. Any ideas? Open a bug report with ARMAsmBackend-265222.cpp and ARMAsmBackend-265222.sh? Cheers, Rafael

I saw this; http://bb.pgr.jp/builders/clang-3stage-cygwin Not sure, though, r195406 triggered this issue. I am still investigating. I guess it could be reproducible with -target i686-* on other hosts. 2013/11/25 Rafael Espíndola <rafael.espindola at gmail.com>: >> ecc: note: diagnostic msg: /tmp/ARMAsmBackend-265222.cpp >> ecc: note: diagnostic msg:

Thanks for the example, that is very useful in working out the overall scope of the problem, which is now wider than I thought it was. I've put some comments inline. On 15 March 2018 at 19:12, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: >> >> Hello everyone, this is most likely Arm specific, but could affect

Hi Chris, > The right place to implement this is in lib/Support/Host.cpp. X86 has an implementation of sys::getHostCPUName(), but everything else just uses the: > > std::string sys::getHostCPUName() { > return "generic"; > } > > implementation. I tried to let it return "armv7l" or "cortex-a9" on pandaboard, but the bitcode output by clang

On 16 March 2018 at 10:38, Peter Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 15 March 2018 at 19:12, Friedman, Eli <efriedma at codeaurora.org> wrote: >> Having ARMv7a instructions in an ARMv4t file shouldn't be a problem: a >> function should be allowed to override the CPU attributes to generate code >> for a newer target. This is generally

On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: > Hello everyone, this is most likely Arm specific, but could affect > other targets where there is a somewhat complex relationship between > the triple and mcpu option. > > At present when clang is used as a linker driver for the gold-plugin > and when using and an explicit -mcpu is not given to clang, then clang > will

Hello everyone, this is most likely Arm specific, but could affect other targets where there is a somewhat complex relationship between the triple and mcpu option. At present when clang is used as a linker driver for the gold-plugin and when using and an explicit -mcpu is not given to clang, then clang will always generate a -Wl,-plugin-opt=mcpu=<default CPU> where the default CPU is based

Hi, I'm trying to move to R the last few data handling routines I was performing in SAS. I'm working on stomach content data. In the simplified example I provide below, there are variables describing the origin of each prey item (nbpc is a ship number, each ship may have been used on different trips, each trip has stations, and individual fish (tagno) can be caught at each

Can you say a Virtualized Asterisk with a PRI card! http://www.phoronix.com/scan.php?page=news_item&px=OTY0OQ Doug -- Ben Franklin quote: "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety."

https://bugs.freedesktop.org/show_bug.cgi?id=101447 Bug ID: 101447 Summary: Nouveau on GP106 can't work with another framebuffer drivers (possibly uvesafb) Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority:

https://bugs.freedesktop.org/show_bug.cgi?id=101448 Bug ID: 101448 Summary: Kernel crashes while using nouveau Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=102913 Bug ID: 102913 Summary: Nouveau on >4.12.12 not loading EDID Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Driver/nouveau Assignee:

> And a big thanks (*not*) to the smart reporting which showed no issues at > all. Heh, on that, did you think to take a look at the Media_Wearout indicator ? I recently learned that existed, and it explained A LOT. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Digital signature URL:

For a target that hasn't implemented branch relaxation (yet), does anyone know what is the preferred way to report an error if a fixup cannot be applied because, for example, the destination of a branch is out of range? I suppose I could use asserts just like AArch64 is doing but that won't stop the assembler of emitting a branch to an undesired location in release builds. Does anyone see