similar to: [RFC] arm64_32: upstreaming ILP32 support for AArch64

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

On Fri, 1 Feb 2019 at 20:08, Matt Arsenault <arsenm2 at gmail.com> wrote: > I don’t see why this would need to be an IR pass. There aren’t all that many places left using the default argument to the various pointer function that can mostly be fixed. iPTR is hopelessly broken on the tablegen side, but you wouldn’t get to that point with this. The difficulty I'm seeing is that we need

On Fri, 1 Feb 2019 at 20:35, Matt Arsenault <arsenm2 at gmail.com> wrote: > Oh right, you don’t have the addrspace in the input. Input to what? Even if it's available it's wrong without a fixup pass. Still, custom override for GEP as you talk about later could overcome the problem... > I have long wanted a way for targets to take over the GEP expansion which may help you?

Hi again, On Fri, 1 Feb 2019 at 19:25, Eli Friedman <efriedma at quicinc.com> wrote: > I don't 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

On Fri, 1 Feb 2019 at 19:25, Eli Friedman <efriedma at quicinc.com> wrote: > > Alternate address-spaces still have just one pointer size per space as > > far as I'm aware. If that's 64-bits we get efficient CodeGen but > > loading or storing a pointer clobbers more data than it should, if > > that's 32-bits then we get poor CodeGen. > > I was

> On Feb 1, 2019, at 2:25 PM, Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > I was thinking of a model something like this: 32-bit pointers are addrspace 0, 64-bit pointers are addrspace 1. ISD::LOAD/STORE in addrspace 0 are not legal: they're custom-lowered to operations in addrspace 1. (An addrspacecast from 0 to 1 is just zero-extension.) At that

AArch64AddressTypePromotion.cpp does a fair bit of work to help make these things work out well. It could probably be generalized for non-AArch64 targets as per the comment in the file header. > On Jun 26, 2014, at 10:42 AM, Sanjay Patel <spatel at rotateright.com> wrote: > > Cool HW trick. :) > Are those 'sxtw' ops free? > That’ll depend on the details of the

Hi Sanjay, The behaviour I’m talking about I’ve actually pinned down to CodeGenPrepare not working too well with ISA’s that don’t have a good scaled load. I have a patch to fix it that is going through performance testing now. Your testcase seems specific to x86 – for aarch64 we get the rather spiffy: _Z3fooPii: // @_Z3fooPii // BB#0:

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Jun Lim via llvm-dev Sent: Thursday, February 22, 2018 11:05 AM Hi All, I found some cases where a spill of a live range in a block is reloaded only in one of its successors, and there is no reload in other paths through other successors. Since the spill is reloaded only in a certain path, it must be okay to sink such

Hi All, I found some cases where a spill of a live range in a block is reloaded only in one of its successors, and there is no reload in other paths through other successors. Since the spill is reloaded only in a certain path, it must be okay to sink such spill close to its reloads. In the AArch64 code below, there is a spill(x2) in the entry, but this value is reloaded only in %bb.1, not in

> From: junbuml at codeaurora.org [mailto:junbuml at codeaurora.org] > Sent: Thursday, February 22, 2018 11:39 AM > > On 2018-02-22 11:14, gberry at codeaurora.org wrote: > > FROM: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] ON BEHALF OF > > Jun Lim via llvm-dev > > SENT: Thursday, February 22, 2018 11:05 AM > > > > Hi All, > > > > I

On 2018-02-22 11:14, gberry at codeaurora.org wrote: > FROM: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] ON BEHALF OF > Jun Lim via llvm-dev > SENT: Thursday, February 22, 2018 11:05 AM > > Hi All, > > I found some cases where a spill of a live range in a block is > reloaded only in one of its successors, and there is no reload in > other paths through other

Hi Guys , Did clang has the support for ILP32 data model on the ARM target like aarch64 /arm64 ? Thank you ~Umesh

On Sat, Sep 23, 2017 at 1:41 AM, Jakub Kicinski via iovisor-dev <iovisor-dev at lists.iovisor.org> wrote: > On Fri, 22 Sep 2017 22:03:47 -0700, Yonghong Song wrote: >> On 9/22/17 9:24 AM, Jakub Kicinski wrote: >> > On Thu, 21 Sep 2017 11:56:55 -0700, Alexei Starovoitov wrote: >> >> On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote:

Looks like your static library is not even pulled into the link command so the static library is not even in the snapshot. From the link command in the snapshot, the static library is not on the command line from snapshot: /Applications/Xcode-11.3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld -Z -demangle -object_path_lto

Me encantaría saber pensar así de una. Creo que entiendo bien lo que me decís, pero no lo puedo poner en marcha en mi computadora, por algo que no sé qué será. Cuando llego a: > cosa<-aline(w1=x,w2=y) En RStudio me dice que R sufrió algo. Probé directamente desde la consola linux y también: > cosa<-aline(w1=x,w2=y) *** stack smashing detected ***: /usr/lib/R/bin/exec/R terminated

Hi Tobias The problem is that your static archive has a SYMDEF that is empty, so linker thinks the static library provided doesn't contain any symbol. The reason for that is you are using the `ranlib` from Xcode, which is too old to understand the new bitcode object files produced by llvm 10. There are lots of ways to fix that: * The standard way to create static library on macOS is to use

On 09/18/2017 10:47 PM, Jiong Wang wrote: > Hi, > > Currently, LLVM eBPF backend always generate code in 64-bit mode, this may > cause troubles when JITing to 32-bit targets. > > For example, it is quite common for XDP eBPF program to access some packet > fields through base + offset that the default eBPF will generate BPF_ALU64 for > the address formation, later when

On Wed, Sep 20, 2017 at 12:20:40AM +0100, Jiong Wang via iovisor-dev wrote: > On 18/09/2017 22:29, Daniel Borkmann wrote: > > On 09/18/2017 10:47 PM, Jiong Wang wrote: > > > Hi, > > > > > >    Currently, LLVM eBPF backend always generate code in 64-bit mode, > > > this may > > > cause troubles when JITing to 32-bit targets. > > >

I am trying to (semi) calculate the confidence intervals for a loess smoother (function: loess()), but have been thus far unsuccessful. The CI for the loess predicted values, yhat, are apparently yhat +- t*s * sqrt(w^2), where s is the residual sum of squares and w is the weight function Correct me of I'm wrong, but R uses the tricubic function (1-abs(z)^3)^3, where z = (x-xi)/h, where h