similar to: difference between --target, -mcpu, -march

On Fri, Mar 18, 2016 at 12:49 PM, Eric Christopher <echristo at gmail.com> wrote: > > > On Wed, Mar 16, 2016 at 2:53 PM Rail Shafigulin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm confused about the clang --target, -mcpu, -march >> >> Can someone give a clear explanation on what is the difference between >> them? >>

> > -Most- targets use -march. > > -eric > Do you meat that in most cases -target is used along with -march instead of -target and -mcpu? -- Rail Shafigulin Software Engineer Esencia Technologies -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160318/9efe3d1b/attachment.html>

Hi I'm doing a port of Clang/LLVM - purely for the educational value - to the MC6809 (and HD6309 as a dub target) processors. I'll also want to eventually provide direct support for the AM9511 floating-point coprocessor as an option. I'm working with bleeding-edge code from the Git mirror. I've made some pretty decent progress; I copied the llvm/lib/Targets/MSP430 Target to

Hi Martin, On Tue, Mar 20, 2018 at 1:18 PM Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Thanks Eric, > > > > After the original reply to my query I had a good look at the GCC > documentation for these options, and what I discovered is that “there is no > consensus” in GCC. Basically, saying do what GCC does was a non-answer as > it clarified nothing.

Thanks very much Eric for taking the time to carefully explain this to me. So if I am the author of the backend for a new processor technology, or willing to modernise my existing implementation, you would recommend that the ‘-mcpu’ option is deprecated and probably best not used at all, or perhaps just as a synonym for ‘-march + -mtune’? The first part of the target triple guides the

On Sat, Mar 12, 2016 at 2:38 PM, Tim Northover <t.p.northover at gmail.com> wrote: > On 12 March 2016 at 11:51, Rail Shafigulin via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I tried every possible combination of --target I could think of but > nothing > > worked. Would you mind helping me out? > > First, 64-bit x86 is "x86_64", and 32-bit

Thanks Eric, After the original reply to my query I had a good look at the GCC documentation for these options, and what I discovered is that “there is no consensus” in GCC. Basically, saying do what GCC does was a non-answer as it clarified nothing. X86 has deprecated ‘-mcpu’ in favour of ‘-mtune’, and it uses ‘-mtune’ to mean that the scheduling, etc. should be biased in favour of more

> > I assume with target you mean the backend? Consider the x86 backend. It > supports 32bit and 64bit mode, with the GNU x32 ABI in between. There > are three different executable formats support (ELF, PE, MachO) with > different constraints. Some platforms require 32bit alignment of the > stack, others require 128bit alignment. The list goes on. The triple > specifies >

Hello, On the appended reasonably simple test case that has an fmul/fadd sequence on <8 x float> vector types, I don't see the x86-64 code generator (with cpu set to haswell or later types) turning it into an AVX2 FMA instructions. Here's the snippet in the output it generates: $ llc -O3 -mcpu=skylake --------------------- .LBB0_2: # =>This Inner

My question is: How do I make clang to generate assembly with vector instruction for my target? The back story is: I've added a few vector instructions to my target and confirmed that they are used by running my code on the test below and using a following command: opt i.esencia.ll -S -march=esencia -mcpu=esencia -loop-vectorize | llc -mcpu=esencia -o i.esencia.s target datalayout =

> > Here is how I started with SelectionDAG: > > - small IR (bugpoint can help) > Did you mean a break poing? - the magic flag: -debug > - read the output of SelectionDAG debugging (especially with cycles) > - matching the log to source code > What log are you talking about? > - single stepping in a debugger sometimes. > > > -- > Mehdi > > -- Rail

On Fri, Mar 18, 2016 at 2:03 PM, Rail Shafigulin <rail at esenciatech.com> wrote: > On Fri, Mar 18, 2016 at 1:53 PM, Mehdi Amini <mehdi.amini at apple.com> > wrote: > >> >> On Mar 18, 2016, at 1:47 PM, Rail Shafigulin <rail at esenciatech.com> >> wrote: >> >> Yes this IR does not build or shuffle any vector. Try to write a function

That's right. In your example, if the target isn't specified anywhere, an llc invocation would be equivalent to "llc -mtriple=x86_64-unknown-linux-gnu -mcpu=generic". TTI queries (in e.g., CodeGenPrepare) would be based on this. From opt, if the target triple is left unspecified, we will use the "base" TTI implementation (not x86). -- Matt On Wed, Nov 30, 2016 at 2:07

Can someone explain what exactly a clang triple is (--triple option) and what is the connection between triple and a target? I know there is an article ( http://clang.llvm.org/docs/CrossCompilation.html) that show how to cross compile code, but I'm not clear about is why I need to specify triple, why I can't just say compile for a given target? Any help is appreciated. -- Rail

> On Mar 18, 2016, at 1:47 PM, Rail Shafigulin <rail at esenciatech.com> wrote: > > Yes this IR does not build or shuffle any vector. Try to write a function that takes 8 ints and a pointer to a <4xi32>, builds two vectors with the 8 ints, > > This might sound like a dumb question, but how does one build a vector of ints out of regular ints in IR? See:

> On May 9, 2020, at 5:12 PM, Andrea Di Biagio via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The llvm scheduling model is quite simple and doesn't allow mca to accurately simulate the execution of individual uOPs. That limitation is sort-of acceptable if you consider how the scheduling model framework was originally designed with a different goal in mind (i.e. machine

Hello, FYI, this is a bug http://llvm.org/bugs/show_bug.cgi?id=13324 When compiling the following code for sm_20, func params are by some reason given with .align 0, which is invalid. Problem does not occur if compiled for sm_10. > cat test.ll ; ModuleID = '__kernelgen_main_module' target datalayout = "e-p:64:64-i64:64:64-f64:64:64-n1:8:16:32:64" target triple =

Hi Alex, On Sun, May 10, 2020 at 4:00 PM Alex Renda <renda at csail.mit.edu> wrote: > Thanks, that’s very helpful! > > > > Also, sorry for the miscue on that bug with the 2/4 cycles — I realize now > that that’s an artifact of a change that I made to not crash when resource > groups overlap without all atomic subunits being specified: > > `echo 'fxrstor

> On Mar 18, 2016, at 1:37 PM, Rail Shafigulin <rail at esenciatech.com> wrote: > >> I think you created a cycle, this is easy to do with SelectionDAG :) >> Basically SelecitonDAG will iterate until it does not see anything to change. So if you insert a transformation on a pattern A, that generates pattern B, while you have another transformation that matches B and

Thanks for everyone giving their feedback! I saw pretty unanimous support for making -mcpu=generic the default and making -mcpu=generic schedule for an in-order CPU (Cortex-A8 in this case). I'll be making those changes shortly. I think the comments also make clear that it's less obvious whether we'd want -mcpu=native to become a default. It's probably good for some use cases, but