similar to: [RFC][ARM] -Oz implies -mthumb

Yes, exactly this: > Sure, none of the cortex-m cores support ARM mode. Try cortex-a{5,7,8,9,15,53} etc and you'll see it works. Sorry for being a bit vague and unclear here: yes, I should have said cortex-a{5,7,8,9,15,53}. I was just having a play with this native compiler: gcc-5 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609 when I noticed that -Os gives me Thumb on

On Thu, 15 Nov 2018 at 14:18, Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > > Ahhh, typo in my previous mail: > > > > when I noticed that -Os gives me Thumb on Cortex-A{8,9,17} > > > I wanted to say: > > > when I noticed that "GCC -Os" gives me Thumb on Cortex-A{8,9,17} > > Yes. Just to clarify my response. That particular linaro

I've never tried -mcpu=cortex-xyz but I know -march=armv7 defaults to Thumb OK, I just checked, and -mcpu=cortex-{m3,m4,m7,a7,a9,a15,a53} gives Thumb at -O1, -O1, -Os on the following gcc: arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.3.0-27ubuntu1~18.04) 7.3.0 cortex-m0 fails because it doesn't do hard float. I don't have an eabi compiler around. On Thu, Nov 15, 2018 at 4:14 AM, Tim

My understanding is that whether a gcc toolchain defaults to ARM or Thumb is a configuration time decision by whomever builds the toolchain. The linaro arm-linux-gnueabihf toolchain I have defaults to -mthumb and that doesn't vary for -mcpu or any other command line option. I haven't got a gcc to hand that defaults to -marm so that I can test whether -mcpu=cortex-m3 will change that to

Hello Sjoerd, Thank you for your response! I was not aware that -Oz is a closer equivalent to GCC's -Os. I tried -Oz when compiling with clang and confirmed that the Clang's generated assembly is equivalent to GCC for the code snippet I posted above. clang --target=armv6m-none-eabi -Oz -fomit-frame-pointer memcpy_alt1: push {r4, lr} movs r3, #0 .LBB0_1: cmp

On Thu, Jun 18, 2020 at 3:37 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > We’re talking about verbose output right? Verbose isn’t the default. > I'm fairly certain the issue in this thread is just the verbosity of -dump-input=fail. Yes, -vv makes it even more verbose by annotating input lines with good matches, etc., but that's not part of the "new

Sorry if I wasn't clear about my use case. In my daily dev work, I do many local "ninja check"s, or "llvm-lit" on a subdirectory as a quick(er) smoke test if I am making changes in that area (e.g. "llvm-lit ../llvm/test/CodeGen"). Nothing wrong here, as indeed nothing changed here. But in case of a test failure, I want to run just that test: bin/llvm-lit

Hi, > The problem I see is that the warning isn't very actionable. Fully agreed. > Good warnings are supposed to be actionable, but what is the developer supposed to do in this case? This diagnostic is unclear. But to be more precise, the first part says the optimisation could not be performed. This is spot on, and an improvement of what we had before because that didn't issue

> I don't know how you proceed to debug FileCheck failures, but for me most of the time I'll have to figure out which "RUN" line fail and try to execute it manually and then remove the FileCheck pipe to get the raw input and then painfully tried to match the FileCheck error to the actual input. Yeah, not very different from what you described here. If I 'm creating or

Yep, exactly that. We see quite a lot of them, most of them get cleaned up, but not always... Cheers. ________________________________ From: Roger Ferrer Ibáñez <rofirrim at gmail.com> Sent: 16 March 2020 08:53 To: Sjoerd Meijer <Sjoerd.Meijer at arm.com> Cc: LLVM-Dev <llvm-dev at lists.llvm.org>; Sam Parker <Sam.Parker at arm.com> Subject: Re: [llvm-dev] Redundant copies

Hi Chris, On Thu, Jun 18, 2020 at 1:37 PM Chris Tetreault via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The thing I use normally only shows the first N lines by default (I don’t > know off hand what N is). Honestly, I don’t feel very strongly about the > specific order, but it’s not useful when somebody proposes something on the > list, and nobody voices any dissent

I would guess that in a CI system the order doesn't matter much because you look at a webpage? I looked at some build bots today/yesterday that now also show this, and yeah, it's fine either way, I was guessing. My primary use-case is usage in a terminal, and displaying the errors first followed by all input makes this pretty unusable. ________________________________ From: Chris

Hi Simon, Thanks for reposting the example, and looking at it more carefully, I think it is very similar to my first proposal. This was met with some resistance here because it dumps loop information in the vector preheader. Doing it this early, we want to emit this in the vectoriser, puts a restriction on (future) optimisations that transform vector loops to honour/update/support this intrinsic

> You have similar problems with https://reviews.llvm.org/D79100 The new revision D79100<https://reviews.llvm.org/D79100> solves your comment 1), and I don't think your comments2) and 3) apply as there are no vendor specific intrinsics involved at all here. Just to quickly discuss the optimisation pipeline, D79100<https://reviews.llvm.org/D79100> is a small extension for the

Invitation accepted, I am happy to help out with reviews, like I did with the previous VP patches. And of course agreed that things should be well defined, and that we shouldn't paint ourselves in a corner, but I don't think that this is the case. And it's not that I am in a rush, but I don't think this change needs to be predicated on a big change landing first like the LV

Thanks for reply. I was using LLVM 8.0. Let me try trunk and will let you know if it works. On Wed, Sep 4, 2019 at 11:19 PM Sjoerd Meijer <Sjoerd.Meijer at arm.com> wrote: > > Hi, > Which version of Clang are you using? I do get a "vfma.f16" with a recent trunk build. I haven't looked at older versions and when this landed, but we had an effort to plug the remaining

Thanks for your replies. That was a very useful discussion. I won't recommit on a Friday afternoon, but will do on Monday, as it looks like we agreed again on the direction and the change. Orthogonal to this change, the interesting topics brought up are improved diagnostics, and the cases the vectoriser misses. I will briefly look why this particular case isn't vectorised, but I suspect

Hello, Quick question to see if I haven't missed anything: I would like convert counting down loops, i.e. loops with a constant -1 step value, to counting up loops, because the vectoriser is able to better deal with these loops (see e.g. D76838 that I was discussing today with Ayal). It looks like LoopSimplifyCFG and IndVarSimplify don't do this. So was just curious if I haven't

Hi Sjoerd We (at Huawei) also have a pass for this. Originally we implemented this back in 2018 and meant to upstream it, but there were some issues with the implementation that required some changes in the code. We started revising it,a few weeks ago. I thought now that there are multiple options, maybe we can discuss our approaches, and see if there is a preference in the community for one

Hi, I abandoned that approach and followed Eli's suggestion, see somewhere earlier in this thread, and emit an intrinsic that represents/calculates the active mask. I've just uploaded a new revision for D79100 that implements this. Cheers. ________________________________ From: Simon Moll <Simon.Moll at EMEA.NEC.COM> Sent: 18 May 2020 13:32 To: Sjoerd Meijer <Sjoerd.Meijer at