search for: stannard

...be running. I think this would explain the FileCheck output from those failing tests. Could there be a buildbot misconfiguration which is preventing the newly-built llvm-tblgen from being used? Oliver From: Galina Kistanova [mailto:gkistanova at gmail.com] Sent: 04 December 2017 22:30 To: Oliver Stannard Cc: Sander De Smalen; nd Subject: Re: buildbot failure in LLVM on llvm-clang-x86_64-expensive-checks-win Hi Oliver, I have requested a clean build of that exact revision and all the tests passes. http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6561 This is kind of...

Thanks all. Amara, could you take a look? > On Nov 20, 2017, at 3:06 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > I’ve raised: > https://bugs.llvm.org/show_bug.cgi?id=35359 <https://bugs.llvm.org/show_bug.cgi?id=35359> > https://bugs.llvm.org/show_bug.cgi?id=35360 <https://bugs.llvm.org/show_bug.cgi?id=35360> > ht...

...and it doesn't support removing elements. To correct this erase needs to decrement all vector indices in the Map which are larger than the removed index. Note that pop_back() does not have this problem as there are no indices following the last one. Yaron 2014-07-15 17:35 GMT+03:00 Oliver Stannard <oliver.stannard at arm.com>: > Do you have a reproducer for this problem? MapVector::erase removes the > value from both the Vector and the Map, so it should not suffer from this > problem. > > > > Oliver > > > > *From:* Yaron Keren [mailto:yaron.keren at gm...

Hi Oliver, Thanks for trying this. Could you file a different PR for each of the problem you found and reference the umbrella PR: http://llvm.org/PR35347? <http://llvm.org/PR35347?> Thanks, -Quentin > On Nov 17, 2017, at 8:17 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > One more reproducer, this time with small (<64bit) values being passed on the stack: > > int foo(int x0, int x1, int x2, int x3, int x4, int x5, int x6, int x7, > int stack1) { > return sta...

...ng, O1 onwards results are wrong! This is because the load and store get hoisted and sinked in the loop in foo, respectively. That happens even though load(p1->f2) and store(p2->f1) are same address, but LLVM doesn’t find it. Thanks, Siddharth ________________________________ From: Oliver Stannard <oliver.stannard at linaro.org> Sent: Friday, February 28, 2020 4:55 PM To: Tiwary, Siddharth <Siddharth.Tiwary at amd.com> Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] TBAA for struct fields [CAUTION: External Email] This is happening becau...

...n Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Thanks Oliver. > I’ll have a look. This typically means that we miss a mapping for this type/instruction, which is not surprising given how little code we have we fp16. > >> On Nov 14, 2017, at 2:27 AM, Oliver Stannard <oliver.stannard at arm.com <mailto:oliver.stannard at arm.com>> wrote: >> >> Hi Quentin, >> >> I’ve started running an ABI test suite with global isel on AArch64, and while it hasn’t found any ABI issues it has hit an assertion in clang when using the __fp16...

> > From: James Henderson via llvm-dev <llvm-dev at lists.llvm.org> > To: Oliver Stannard <oliver.stannard at linaro.org> > Cc: LLVM Dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] [RFC] Case insensitive assembly directives for > all targets > > +1 to all of what Oliver said. We aim for compatibility with GNU in most > (all?) of our o...

Hi llvm-dev, I've uploaded a prototype patch at https://reviews.llvm.org/D70720 which adds a new feature to llvm-objdump: displaying the location (in registers/memory/etc) of source-level variables alongside the disassembly display. I've put a demo of the output at https://reviews.llvm.org/M2. I have two use-cases in mind for this: * Users reading the disassembly of compiled code. It

Hi, We currently have a downstream patch (attached) which implements some new addressing modes that enable position-independent code for small embedded systems. Is this something that would be accepted upstream? I think the ARM backend changes are fairly uncontroversial, but the clang changes introduce a lot of ROPI/RWPI specific changes in otherwise target-independent code. If the clang changes

GCC-style inline assembly is notoriously hard to write correctly, because it is the user's responsibility to tell the compiler about the requirements of the assembly (inputs, output, modified registers, memory access), and getting this wrong results in silently generating incorrect code. This is also dependent on register allocation and scheduling decisions made by the compiler, so an inline

On Wed, 24 Jul 2019 at 10:52, Oliver Stannard via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Your script looks OK, though you won't want to use the -opt-bisect-limit= > option until you've found a case where code-generation changes. Instead, > that's a tool which you could use to narrow down the pass inside LLV...

...er][AArch64] Keep track of functions that use a red zone in AArch64MachineFunctionInfo and use that instead of checking for noredzone in the MachineOutliner' by Jessica Paquette [0.00%/25.00%] https://reviews.llvm.org/D46107 '[AArch64] Codegen for v8.2A dot product intrinsics' by Oliver Stannard [0.00%/12.50%] https://reviews.llvm.org/D45541 '[globalisel] Update GlobalISel emitter to match new representation of extending loads' by Daniel Sanders [0.00%/6.25%] https://reviews.llvm.org/D44386 '[x86] Introduce the pconfig/enclv instructions' by Gabor Buella The first percent...

Hi all, I'm trying to see if I can use a global static base register instead of PC-relative addressing. I see that I can easily reserve R9 in the ARM Subtarget, but this doesn't let me use it. I found a TODO in ARMAsmPrinter.cpp that refers to this: // TODO: We currently only support either reserving the register, or treating // it as another callee-saved register, but not as SB or a

...f your current PR though. -jameson On Wed, Nov 27, 2019 at 1:51 PM Sean Silva via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This looks fantastic. It will be a big time saver for folks staring at > assembly. > > — Sean Silva > > On Tue, Nov 26, 2019 at 8:50 AM Oliver Stannard via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi llvm-dev, >> >> I've uploaded a prototype patch at https://reviews.llvm.org/D70720 which >> adds a new feature to llvm-objdump: displaying the location (in >> registers/memory/etc) of source-le...

...ack of functions that use a red zone in AArch64MachineFunctionInfo > and use that instead of checking for noredzone in the MachineOutliner' by > Jessica Paquette > [0.00%/25.00%] https://reviews.llvm.org/D46107 '[AArch64] Codegen for v8.2A > dot product intrinsics' by Oliver Stannard > [0.00%/12.50%] https://reviews.llvm.org/D45541 '[globalisel] Update > GlobalISel emitter to match new representation of extending loads' by Daniel > Sanders > [0.00%/6.25%] https://reviews.llvm.org/D44386 '[x86] Introduce the > pconfig/enclv instructions' by Gabor B...

[AMD Official Use Only - Internal Distribution Only] Hi, Following issue is observed with Type Based Alias Analysis(TBAA). ####################################################### struct P { float f1; float f2; float f3[3]; float f4; }; void foo(struct P* p1, struct P* p2) { p1->f2 = 1.2; p2->f1 = 3.7; } int callFoo() { struct P p; foo(&p, &(p.f2)); }

...ate further if required. I am quite new to Linux and still have a lot to learn. Am I thinking along the right lines that I need to learn about iptables or would ebtables be a better route to go down? The simplest solution that does not require too much learning would be best! Best Regards Robert Stannard

Hi Quentin, I’ve started running an ABI test suite with global isel on AArch64, and while it hasn’t found any ABI issues it has hit an assertion in clang when using the __fp16 type. Here’s a reproducer: __fp16 pass_f16(__fp16 p) { return p; } $ /work/llvm/build/bin/clang --target=aarch64-arm-none-eabi -march=armv8-a -c test.c -O0 -mllvm -global-isel -mllvm -global-isel-abort=0

Hi In my MC6809 backend, in llvm/lib/Target/MC6809/InstPrinter/MC6809InstPrinter.cpp, I have the routine void MC6809InstPrinter::printPCRelImmOperand(const MCInst *MI, unsigned OpNo, raw_ostream &O) { const MCOperand &Op = MI->getOperand(OpNo); ZZ if (Op.isImm()) { int64_t Imm = Op.getImm() + 2; <<<======================== O << "$"; if (Imm

...ally type cast each register access. cheers, sam Sam Parker Compilation Tools Engineer | Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . Arm.com ________________________________ From: Sjoerd Meijer Sent: 18 January 2018 13:58:29 To: Friedman, Eli; Sjoerd Meijer; Sam Parker; Oliver Stannard; llvm-dev at lists.llvm.org Cc: nd Subject: Re: [llvm-dev] [RFC] Half-Precision Support in the Arm Backends I would like to revive this thread, as I am struggling a lot with the FP16 implementation in the ARM backend. My implementation in https://reviews.llvm.org/D38315 is finished (except one ca...