similar to: Target specific named address spaces

Hello, This is an RFC for adding intrinsics which perform saturating signed/unsigned left shift. There is currently a patch on Phabricator here: https://reviews.llvm.org/D83216 The intrinsics are of the form i32 @llvm.sshl.sat.i32(i32, i32) i32 @llvm.ushl.sat.i32(i32, i32) <4 x i32> @llvm.sshl.sat.v4i32(<4 x i32>, <4 x i32>) <4 x i32>

Hi all, I got a interesting problem when calling getNumOperands() of CallInst. For example, call void @_Z2f2PA100_i([100 x i32]* nonnull %arraydecay) If I use getNumOperands(), it will return 2. However, if I use getCalledFunction()->getNumParams(), it will return 1. According to the IR, I think the number of operands of the call instruction should be 1. I

Hello all, I've followed the example in https://github.com/CompilerTeaching/SimplePass/blob/master/SimplePass.cc in order to create a custom pass. The pass needs to be added before any transformation, so I used EP_EarlyAsPossible extension point to register it. Furthermore, I need to access to every GlobalVariable in the IR, so my pass has to be a ModulePass, like this: struct MyPass :

Hello Paul, Thanks for the reply. Yes, I am only looking for dwarf support at the moment and planning to support both PLI/COBOL decimal types. Also thanks for the suggestion, you are right as it is going to be rare cases, so it will be better to implement a separate subclass to avoid memory overhead for others. >> (Somebody is actively working on scaled binary operations, although they

On 2015-04-28 19:14, Quentin Colombet wrote: > Personally I would rather not have to write YAML inputs but instead > resort on the what the machine dumps look like. That being said, I can > live with YAML :). > YAML is what is suggested in the FIXME for the textual Machine IR, so that might be the motivation behind Alex's choice. I sort of agree that it could be better to go

2015-04-28 10:15 GMT-07:00 Hal Finkel <hfinkel at anl.gov>: > > ------------------------------ > > *From: *"Alex L" <arphaman at gmail.com> > *To: *"LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > *Sent: *Tuesday, April 28, 2015 11:56:42 AM > *Subject: *[LLVMdev] RFC: Machine Level IR text-based serialization format > >

> On Jul 3, 2019, at 4:43 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -----Original Message----- > From: David Greene <dag at cray.com> > Sent: Wednesday, July 3, 2019 2:44 PM > To: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> > Cc: Krzysztof Parzyszek <kparzysz at quicinc.com> > Subject: [EXT] Re:

We would like to discuss the possibility of adding support for fixed point operations, either through new types, instructions, or intrinsics. This is an extension to a previous proposal (http://lists.llvm.org/pipermail/cfe-dev/2018-April/057756.html) for implementing fixed point arithmetic entirely in clang, but John McCall brings up good points in the comments thread of

To get this out first: I'd love to have a way to serialize machine-IR! I often spend a lot of time trying to create .ll files in a way that the machine-IR still looks a certain way when it finally hits the relevant passes in codegen. It would be so much easier to just specify the machine IR immediately before the pass I'm interested in. For that use case it is worth keeping the following

On 2018-08-22 05:56, John McCall via llvm-dev wrote: >> On Aug 21, 2018, at 6:20 PM, Leonard Chan <leonardchan at google.com> wrote: >> If we were to create a new type down the line, I think the main >> features that would distinguish them from other types are the >> arbitrary width and scale. Saturation can be handled through >> instructions since saturation

Hi all, Just to inform that we have an open position for a compiler engineer: https://www.kalrayinc.com/compiler-engineer/ The position is in Grenoble, France. Regards, Sebastien Sébastien Le Duc CoreSW Team Manager <http://www.kalray.eu/> kalray_logo Kalray S.A. <http://www.kalray.eu> www.kalray.eu Phone : 06 84 43 07 00 sleduc at kalray.eu Follow us

On 2018-08-22 11:32, John McCall wrote: > >> On Aug 22, 2018, at 4:38 AM, Bevin Hansson <bevin.hansson at ericsson.com> wrote: >> >> >> >> On 2018-08-22 05:56, John McCall via llvm-dev wrote: >>>> On Aug 21, 2018, at 6:20 PM, Leonard Chan <leonardchan at google.com> wrote: >>>> If we were to create a new type down the line, I

If we were to create a new type down the line, I think the main features that would distinguish them from other types are the arbitrary width and scale. Saturation can be handled through instructions since saturation really only takes effect after an operation and doesn’t really describe anything about the bits in the resulting type. Signage can similarly be managed through operations and would be

I'm a new LLVM developer contributing patches for the AVR platform and I'm trying to understand which parts of the code base are malfunctioning in my case. This LLVM IR... define hidden i32 @setServoAngle3(i32) local_unnamed_addr { entry: %1 = call i32 @myExternalFunction1(i32 %0, i32 119) ret i32 %1 } declare i32 @myExternalFunction1(i32, i32) Is being lowered to this assembly

After *much* digging and playing around, I finally figured out how to unit test instance variables that are created by actions. It was more difficult than I expected. It seems like there should have been a more straight forward way to do this. Can someone enlighten me? A simplified and somewhat contrived example of what I am current doing: Thanks. Matt >> # My Controller of interest

Hi all, I would like to propose a text-based, human readable format that will be used to serialize the machine level IR. The major goal of this format is to allow LLVM to save the machine level IR after any code generation pass and then to load it again and continue running passes on the machine level IR. The primary use case of this format is to enable easier testing process for the code

Hi all, I have an Samba + LDAP PDC and BDC setup with a trust to an NT 4 domain. I am using Samba 3.0.21c on Sles 9. HRH is the Samba domain and Hendricks is the NT4 domain. When using getent passwd and/or wbinfo -u on the pdc all of the users from both domains are listed: getent passwd: <snip>HRH users: njcloud:x:1034:1014:System User:/home/njcloud:/bin/bash acrardi:x:1035:513:System