search for: hibbit

...o me. I don't think this is excessively intrusive and it accomplishes what is needed by targets whose call lowering can introduce illegal types. Adding Justin Bogner as the owner of SDAG and Hal Finkel as the PPC back end owner for their opinions. Nemanja On Thu, Jan 3, 2019 at 4:54 PM Justin Hibbits <jrh29 at alumni.cwru.edu<mailto:jrh29 at alumni.cwru.edu>> wrote: Hi Nemanja, I'm attaching a patch that builds on D54583 and implements what we discussed on IRC earlier today. Particularly: * Make LowerCallTo() a virtual function, so it can be wrapped by a subclass. * Implem...

...if you could provide the DAG before > and after legalization both with and without your patch. Then we can > see how it was handled before your patch and how it is handled now > and the difference should allude to the problem. > > N > > On Wed, Jan 2, 2019 at 10:54 AM Justin Hibbits via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > Hi, > > > > I have a custom lowering operation on ISD::BITCAST for the > > PowerPC/SPE target, to convert 'f64 bitcast (i64 build_pair i32, > > i32)' into a 'f64 BUILD_SPE64 i32, i32...

...ively intrusive > and it accomplishes what is needed by targets whose call lowering can > introduce illegal types. > Adding Justin Bogner as the owner of SDAG and Hal Finkel as the PPC back > end owner for their opinions. > > Nemanja > > On Thu, Jan 3, 2019 at 4:54 PM Justin Hibbits <jrh29 at alumni.cwru.edu> > wrote: > >> Hi Nemanja, >> >> I'm attaching a patch that builds on D54583 and implements what we >> discussed on IRC earlier today. Particularly: >> >> * Make LowerCallTo() a virtual function, so it can be wrapped by...

Hi, I have a custom lowering operation on ISD::BITCAST for the PowerPC/SPE target, to convert 'f64 bitcast (i64 build_pair i32, i32)' into a 'f64 BUILD_SPE64 i32, i32' node, which can be seen at https://reviews.llvm.org/D54583. However, when building compiler-rt's lib/builtins/divdc3.c an assertion is triggered that BUILD_PAIR is not legal on line 24. There should be no

I'm trying to add intrinsics for the Signal Processing Engine (FPU/vector unit) on some PowerPC cores, but running into a problem. Some of the instructions take an immediate operand, but I can't figure out how to make the intrinsic use an immediate, it just wants to load a register as an argument to the function. Is there any way in the .td file to describe the intrinsic as taking an

I think that's incorrect. It should to: .section .foo .L1: .L2 = .L1 .section .bar .long .L3-.L2 .L3: Because .L3 and .L2 are in different sections. - Justin On Thu, Jun 26, 2014 at 2:46 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > This reduces to > > .section .foo > .L1: > .L2 = .L1 > .section .bar > .long .L1-.L2 > > > Which is fairly

I'm working on Position-independent code for 32-bit PowerPC, but running into a problem. At the beginning of each function, there's a pre-word that's the difference between the PICBase (.L1$pb) and the GOT. This works fine when generating assembly output, but it fails when generating ELF output, with the error "Cannot represent a difference across sections" (line 847,

Hi, everyone, I would like to know if anyone is still making use of the support in the PowerPC backend for the IBM BG/Q supercomputer, including the support for its QPX vector instruction set. If you are, please reply. I'm not aware of any still-running BG/Q machines, and if no one is making use of this functionality, I propose that we remove it. Thanks again, Hal Hal Finkel Lead, Compiler

On 2020-06-19, Justin Hibbits via llvm-dev wrote: >On Fri, 19 Jun 2020 17:38:02 +0100 >Renato Golin <rengolin at gmail.com> wrote: > >> On Fri, 19 Jun 2020 at 16:43, Robinson, Paul via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > If anyone's keeping track of the voting: &gt...

I'm trying to fix a bug in the PowerPC SPE backend that prevents a bunch of FreeBSD ports from building, including gtk20. The attached file, generated from the following C source, triggers the "Def == PreviousDef" assertion in isNopCopy(): typedef float a; typedef struct { a b, c; } complex; d(complex *e, complex *h) { double f = h->c, g = h->b; i(g); e->c = g *

Attached. You can also find it at http://people.freebsd.org/~jhibbits/hello_llvm.s . - Justin On Thu, Jun 26, 2014 at 1:26 PM, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > > Sent from my iPhone > >> On Jun 26, 2014, at 12:33, Justin Hibbits <jrh29 at alumni.cwru.edu> wrote: >> >> I'm working on...

On Fri, 19 Jun 2020 14:46:19 +0000 "Keane, Erich via llvm-dev" <llvm-dev at lists.llvm.org> wrote: > If the name of our branch causes anxiety/difficulty for a significant > portion of our population, it is literally the least we can do to > choose a word that better respects the last few centuries of world > history. Honestly, if the name of a branch causes

On Fri, 19 Jun 2020 14:45:37 +0100 Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Fri, 19 Jun 2020 at 12:57, Hal Finkel via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I like "dev" as an option here. It's short, and in addition, > > conveys the fact that the development happens in that branch. > > "main" in

On Fri, 19 Jun 2020 at 16:43, Robinson, Paul via llvm-dev <llvm-dev at lists.llvm.org> wrote: > If anyone's keeping track of the voting: > +1 for "dev" (contrasts with "release") > +1 for "trunk" (historical and consistent with the branch metaphor) > -1 for "main" Hey! At least one +1 for "main" from me! Also, on -1 for

On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote: > > From: Daniel Sanders > > Sent: 25 November 2014 17:39 > > To: Eric Christopher; Tom Stellard > > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > > > I'd also like to propose the inclusion of

...wners to get their approval. It might help to send a separate email per code owner. Thanks, Tom > > Enabling TLS support for PowerPC32: > > http://llvm.org/viewvc/llvm-project?rev=213960&view=rev > > [PowerPC] Support TLS on PPC32/ELF > > Patch by Justin Hibbits! > > > Two changes needed for being able to link lldb 3.5.x against llvm 3.5.x: > > http://llvm.org/viewvc/llvm-project?rev=215352&view=rev > > AArch64: add support for dynamic-loader relocations > > LLD needs them, and it's good to be able to prin...