search for: tnorthover

On 1 Oct 2013, at 14:49, Tim Northover <tnorthover at apple.com> wrote: > We're hoping to get rid of the old one soon, but there are one or two features that don't quite work there yet. Lazy compilation is the only one I know of, since we got multi-module support yesterday. But there may be more. Can MCJIT handle thread-local refere...

Hi Mayur, > On 24 Nov 2014, at 07:00, MAYUR PANDEY <mayur.p at samsung.com> wrote: > In the assembly generated with O0, we are getting the "blx" instruction whereas with O1 we get "bx" (in 3.4.2 we used to get "blx" for both O0 and O1). > > Is this because of this patch: [llvm] r214959 - ARM: do not generate BLX instructions on Cortex-M CPUs

...Date: Sat Mar 29 18:00:49 2014 +0000 ARM64: Remove unused helper function, make others static. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 205112 91177308-0d34-0410-b5e6-96231b3b80d8 --- Clang commit d57bb79310cadab07ed3b56d0de55318916f2fb0 Author: Tim Northover <tnorthover at apple.com> Date: Sat Mar 29 17:35:34 2014 +0000 Install: add arm_neon.h header back I'd gone too far pruning aarch64_simd.h this time and took out one instance of arm_neon.h. This should restore us to the status quo. git-svn-id: https://llvm.org/svn/llvm-project/c...

Hi Junbum, > I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced? They're not allocated during CodeGen because of the Reserved.set(…) calls in

Hi, I have a question about the definitions of t2LDRSB and t2LDRSB_PRE in ARMInstrThumb2.td : I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced?

...know that this ends up being easier to implement overall, but the model is closer to what the hardware actually supports, and it involves fewer changes to target-independent code. I've now got something about largely working via an IR-level lowering pass (pushed to GitHub as https://github.com/TNorthover/llvm-project/tree/arm64_32-arch-pass, please excuse any artefacts of incompleteness). I feel like it's rapidly approaching an unpalatability horizon though. Most issues stem from the fact that not all pointers are visible or controllable in the IR: + FrameIndices: you can't change an all...

Hi Dirkjan, > I've tried looking for this error, but can't seem to find any more information on what the cause of this could be. This looks like a backtrace from the legacy JIT. Unfortunately that's known to be broken on ARM and you should use the MCJIT instead (see tools/lli/lli.cpp for an example of how to enable it). We're hoping to get rid of the old one soon, but there

...Kumar <vedant_kumar at apple.com> Sent: 30 September 2019 20:50 To: David Tellenbach <David.Tellenbach at arm.com> Cc: paul.robinson at sony.com <paul.robinson at sony.com>; llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>; nd <nd at arm.com>; Tim Northover <tnorthover at apple.com>; Ahmed Bougacha <abougacha at apple.com> Subject: Re: [llvm-dev] [AArch64] Generated assembly differs depending on whether debug information is generated or not Hi David, Thanks for looking into this. It seems like D68076 might not address the underlying issue here (e.g. i...

Hello all, When using the JIT on ARM, I get the following error message. The code works fine on both X86 32 and 64 bit architectures. rbx: /home/dirkjan/llvm-3.3.src/include/llvm/CodeGen/MachineOperand.h:260: unsigned int llvm::MachineOperand::getReg() const: Assertion `isReg() && "This is not a register operand!"' failed. Program received signal SIGABRT, Aborted.

...dgregor,djasper,dyatkovskiy,echristo,efriedma,evancheng,fjahanian,gps,gribozavr,grosbach,grosser,hanm,hans,hliao,jacksprat,jaykang10,jrose,jush,kcc,klimek,kremenek,matthewbg,mcrosier,mspencer,nadav,nicholas,panzer,pranavb,rafael,rdivacky,resistor,rjmccall,rsmith,rtrieu,spop,spyffe,stoklund,tbrethou,tnorthover,victorm,void,zaks > > BUILD FAILED: failed clang-test > > sincerely, > -The Buildbot > > >

...cause of the "some" distinction between the writeback and non-writeback versions. Is there any benefit from the inconsistency by using GRP in .td file and freezing lr and pc during register allocation in writeback version? Thanks, Junbum On May 23, 2013, at 11:51 AM, Tim Northover <tnorthover at apple.com> wrote: > Hi Junbum, > >> I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case,...

Hi, I enabled the loop vectorizer for -O2 and -Os in r184084. Please let me know if you are experiencing any regressions. Thanks for all the people who contributed, evaluated, measured and reviewed this code. You are the best! Thanks, Nadav

> I enabled the loop vectorizer for -O2 and -Os in r184084. Congratulations! A lot of hard work went into getting us here. Tim.

...spencer,nadav,nicholas,nico,olesalscheider,papin_g,pcc,predmond,rafael,rdivacky,redstar,rengolin,resistor,revane,ributzka,rikka,rkotler,rlytton,rmitton,rnk,row,rsandifo,rsmith,rtrieu,rudkx,ruiu,samsonov,sbaranga,sbenza,sdt,sepavloff,shuxin_yang,silvas,stephenwlin,stoklund,sylvestre,tasiraj,timurrrr,tnorthover,tstellar,uweigand,venkatra,vmedic,void,whunt,wpan,wschmidt,ygao,yjiang > > BUILD FAILED: failed compile > > sincerely, > -The Buildbot > > >

On 18 May 2016 at 17:32, Tim Northover <t.p.northover at gmail.com> wrote: > That's the thing: this shouldn't have changed at all recently. We emit > "b.w dest" with an R_ARM_THM_JUMP24 reloc. The linker then needs a > veneer if dest is out of range or an ARM function. Peter has just reminded me the fact that the relocation itself is in libstdc++, not on the

> On Jul 19, 2016, at 6:00 PM, Tim Northover <t.p.northover at gmail.com> wrote: > > On 19 July 2016 at 17:54, Tim Northover <t.p.northover at gmail.com> wrote: >> Yep, I think the main benefit (so far) over just protected branches >> would be that we can also guarantee sane timestamps on master, What about linear history? Does not this require the "status

So, there's been a bit of a misunderstanding about the hooks that are supported in GitHub, and after talking to the GitHub staff, I'd like to clarify what they are and how we can use them. 1. Pre-commit hooks, avoiding forced pushes / re-order GitHub doesn't support server hooks due to security concerns. But there is an alternative:

> pointers. If you're writing a front-end this probably means you need > to keep your AST's representation of element types alongside LLVM > pointer Values in your own data-structures Yeah, that’s no problem - the type is needed for signed/unsigned integer distinctions anyway. There’s no getting around having one’s own type hierarchy. >> And also - is it possible to use

Hi all, At the dev meeting I promised to update everyone on where my work with opaque pointers is right now. It's taken me a while, but at least it's the same year! Current Status ============== I've put two branches up at https://github.com/TNorthover/llvm-project: "opaque-ptr" which has most of the real work so far; and "opaque-ptr-always" that additionally has a patch to force every pointer to be opaque and see what falls over. It's about 40 patches on top of master in a few categories. 1. Serialization: bitcode <-&...

Hi Eli, Thanks for the comments. On Thu, 31 Jan 2019 at 19:48, Eli Friedman <efriedma at quicinc.com> wrote: > > We teach CodeGenPrepare to sink GEPs as GEPs, and preserve the > > inbounds marker. This is the only way they can possibly be exposed to > > SDAG at the basic block level. > > Isn't addr-sink-using-gep already a thing? Yes, I'm not sure why I