similar to: [LLVMdev] prevent frontend from emitting i64

Generally legalize at IR level is not a good idea. But if you need legalization on IR code, you can check PNaCl project. https://chromium.googlesource.com/native_client/pnacl-llvm/ The pass is located at: lib/Transforms/NaCl/ExpandLargeIntegers.cpp You need make some change, as the pass split large integer into 64bit integers. 2015-01-29 16:06 GMT+08:00 Alon Shaltiel (ashaltie) <ashaltie at

Hello, I'm trying to extract the value out of my MDNode, but for some reason I can't. For example, if one part of the code gets an MDNode that was created as follows: Metadata* vals[2] = { ValueAsMetadata::get(&F), ValueAsMetadata::get(ConstantInt::get(context, 135)) }; MDNode* mdnode = MDNode::get(context, vals); Is it possible to extract the value of the constant int

> On Dec 21, 2016, at 10:26, Ruiling Song <ruiling.song83 at gmail.com> wrote: > > > > 2016-12-20 22:14 GMT+08:00 Tom Stellard <tom at stellard.net <mailto:tom at stellard.net>>: > > > > On Tue, Dec 20, 2016 at 11:00:09AM +0800, Ruiling Song wrote: > > > Hi, > > > > > > I am working on a new LLVM target for Intel GPU, which

Some code in GVN.cpp: static Value *CoerceAvailableValueToLoadType(Value *StoredVal, Type *LoadedTy, Instruction *InsertPt, const DataLayout &DL) { .... // Convert vectors and fp to integer, which can be manipulated. if (!StoredValTy->isIntegerTy()) {

On Wed, Dec 21, 2016 at 10:31:57AM -0500, Matt Arsenault wrote: > > > On Dec 21, 2016, at 10:26, Ruiling Song <ruiling.song83 at gmail.com> wrote: > > > > > > > > 2016-12-20 22:14 GMT+08:00 Tom Stellard <tom at stellard.net <mailto:tom at stellard.net>>: > > > > > > On Tue, Dec 20, 2016 at 11:00:09AM +0800, Ruiling Song

Hi, I am currently working on an opencl project based on LLVM, the target device is 32bit. I met a problem that some llvm passes like GVN SROA will generate some IR operating on wide integer types like i128 or i512. But the device does not support such kind of data type. Is there any idea on how to lower this kind of IR to only operate on i32 or vector of i32? Or is there any existing code handle

2016-12-20 22:14 GMT+08:00 Tom Stellard <tom at stellard.net>: > > On Tue, Dec 20, 2016 at 11:00:09AM +0800, Ruiling Song wrote: > > Hi, > > > > I am working on a new LLVM target for Intel GPU, which also has same kind > > of scalar/vector register classes used in AMDGPU target. Like for a i32 > > virtual register, it will be held in scalar register if its

Hi all, I'm looking for a way to insert metadata into an instruction/function/basic-block in the IR level, and afterwards reading it in the backend (ARM to be exact). So my questions are: 1. Does/can the metadata in the IR survive the code-generator in some way? 2. Is there a general of 'communication' between the optimizer and the backend? Thanks! Alon

Hi Escha, Great to have your comment! Do you have any specific reason for not doing like this? I am not sure whether I understand your point correctly. For "just model one thread", do you mean "only considering ONE of the 8/16 working lanes that running in lock-step way"?? For my case, may be something like I only need to define r0~r127 as register for i32 register (each r#

Hi all, BitstreamReader is the only in-tree client of the DataStreamer and MemoryObject interfaces. In practice when using user-facing LLVM tools, the bitcode will normally either be in memory or in a file, so the best way to access it is through memory, either directly or memory mapped. As part of some refactorings I am making to BitstreamReader, I would like to simplify it by changing it to

And on a separate thread [0] Derek indicated he'd be fine with removing it. I'll leave this thread open until end of Monday to receive any other opinions, then proceed to remove it. Peter [0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161024/400754.html On Fri, Oct 28, 2016 at 10:08 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Hi all, > >

Hi, I want to get the information where the address of load/store comes from, like below load instruction, %152 may come from a getelementpr, or comes from some gep+ptrtoint+add+inttoptr... instructions. what's the recommended way to find the original memory pointer? %153 = load <2 x i16> addrspace(1)* %152, align 2 going through the use-def chain seems not easy, because the

Awesome! Thanks, Rafael On 28 October 2016 at 13:14, Peter Collingbourne <peter at pcc.me.uk> wrote: > And on a separate thread [0] Derek indicated he'd be fine with removing it. > I'll leave this thread open until end of Monday to receive any other > opinions, then proceed to remove it. > > Peter > > [0] >

The PNaCl project has implemented various IR simplification passes that simplify LLVM IR by lowering complex features to simpler features. We'd like to upstream some of these IR passes to LLVM. We'd like to explore if this acceptable, and if so, how we should go about doing this. The immediate reason is that Emscripten is reusing PNaCl's IR passes for its new "fastcomp"

Am 19.06.2013 18:01, schrieb JF Bastien: > > From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program > because ABIs are different (e.g. PNaCl pointers are always 32-bit > even when running on x86_64 platform). > So PNaCl program can't access any data structures of the host >

> From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program because > ABIs are different (e.g. PNaCl pointers are always 32-bit even when running > on x86_64 platform). > So PNaCl program can't access any data structures of the host program > directly. The only communication way is by using syscalls,

Hi Greg, Our repos are public already, hosted on the Chromium infrastructure. Our builds are based out of the Native Client repository. The nacl git mirror is at http://git.chromium.org/native_client/src/native_client.git (no gitweb, sorry). That repo has pointers to a bunch of other repos which make pnacl (LLVM, clang, binutils, and a few others. see the file pnacl/DEPS for more). But if you just

> -----Original Message----- > From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com] On > Behalf Of Michael Kruse > Sent: Wednesday, October 18, 2017 1:18 PM > To: Song, Ruiling <ruiling.song at intel.com> > Cc: Michael Kruse <llvm at meinersbur.de>; llvm-dev at lists.llvm.org > Subject: Re: Possible bug of Alias Analysis? > > 2017-10-18

Hi Eli, > we are splitting the effort to manageable chunks that can > be committed, tested and reviewed separately as > independently as feasible I'd be interested in experimenting with this stuff sooner than later. Could you dump all the patches in a publicly accessible repo? How about Github? Thanks, Greg On Tue, Dec 4, 2012 at 3:53 PM, Eli Bendersky <eliben at

> -----Original Message----- > From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com] On > Behalf Of Michael Kruse > Sent: Tuesday, October 17, 2017 3:26 PM > To: Song, Ruiling <ruiling.song at intel.com> > Cc: llvm at meinersbur.de; llvm-dev at lists.llvm.org > Subject: Re: Possible bug of Alias Analysis? > > 2017-10-17 8:45 GMT+02:00 Song,