similar to: [RFC] [PowerPC] Removing PowerPC QPX Support

Dear LLVM contributors, I am Naoki Shibata, an associate professor at Nara Institute of Science and Technology. I and Hal Finkel would like to jointly propose to add my vectorized math library to LLVM. The library has been available as public domain software for years, I am going to double-license the library if necessary. ******** Below is a proposal to add my vectorized math library,

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. * Implement LowerCallTo() in PPCTargetLowering to wrap TargetLowering::LowerCallTo() and legalize the return node when targeting SPE. * Augment PPCTargetLowering::LowerCall_32SVR4() to

Aside from the fact that you're checking for i64 specifically instead of generally checking for illegal types, how much of this is really PPC specific? Would this be a reasonable enhancement to the SDAG logic in general? -Hal On 1/4/19 8:03 AM, Nemanja Ivanovic wrote: The changes seem fine to me. I don't think this is excessively intrusive and it accomplishes what is needed by targets

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

+ Eli Friedman as he often has very insightful comments regarding back end changes. On Fri, Jan 4, 2019 at 9:03 AM Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > The changes seem fine to 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

Hi All, I have faced decoding conflict of DisassemblerTables from TableGen. I have instructions with same encoding and different mnemonic among different architecture versions. I have used Predicates and AssemblerPredicates to distinguish them on Codegen and Assembler but it does not work on Disassembler. When I look at TableGen/FixedLenDecoderEmitter.cpp, once there is decoding conflict,

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,

Dear everyone, The in-progress release notes for 3.7 [1,2] make it look like we didn't do very much over the past six months. Obviously that's not the case at all, so let's get them in shape! If you've been thinking "I should probably add this to the release notes at some point", now is the time :-) I have a list below of changes that might be worth mentioning. I

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: >> > +1 for "dev" (contrasts with "release")

I've been working on adding support for a (semi-proprietary) extension for PowerPC called "Paired-Singles". It's a SIMD instruction set supporting various operations on a vector of 2 32-bit floating point numbers. The Extension is found in the PowerPC 750CL, modified variants of it are used in the Nintendo GameCube (Gekko), the Nintendo Wii (Broadway) and the Nintendo Wii U

----- Original Message ----- > From: "Pete Cooper" <peter_cooper at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVMdev" <llvmdev at cs.uiuc.edu>, "Paweł Bylica" <chfast at gmail.com> > Sent: Wednesday, July 1, 2015 6:42:41 PM > Subject: Re: [LLVMdev] extractelement causes memory access violation - what to

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 *

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

----- Original Message ----- > From: "David Majnemer" <david.majnemer at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Pete Cooper" <peter_cooper at apple.com>, "LLVMdev" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, July 1, 2015 7:17:19 PM > Subject: Re: [LLVMdev] extractelement causes memory access violation

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

What would be needed in order to make MCJIT work on a new architecture? I am thinking BG/Q and Xeon Phi (native). Let's assume the components required for JIT (core, mcjit, native, etc.) can be cross-compiled and linked with an Intel or IBM compiler for such an architecture, and somehow one manages to execute the application. (I didn't try all that yet.) Also, let's assume there is

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