similar to: How to describe the RegisterInfo?

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#

Yes, the arch is just as you said, something like AMD GPU, but Intel GPU don't have separate register file for 'scalar/vector'. In fact my idea of defining the register tuples was borrowed from SIRegisterInfo.td in AMD GPU. But seems that AMD GPU mainly support i32/i64 register type, while Intel GPU also support byte/short register type. So I have to start defining the registers from

Hi all, I just committed r183020 and r183061, that add Size/Offset information to SubRegIndex. If you maintain an out-of-tree target, there are a few things to change: - the SubRegIndex class has a new mandatory argument, representing the Size (in bits) covered by the index. If it's not meaningful (ex: same index for different kinds of registers), set it to -1 (though I believe this

I have made changes in 3 files: LaneBitmask.h, codegenregisters.cpp and miparser.cpp. files are attached here. Now i am getting following errors. which means registerinfo.inc file is not generated successfully. /PIM/lib/Target/X86/MCTargetDesc/X86BaseInfo.h:733:24: error: no member named 'XMM8' in namespace 'llvm::X86' if ((RegNo >= X86::XMM8 && RegNo <=

> 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

> -----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

> -----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,

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 an out-of-tree user of llvm. I am running into an regression issue against llvm 5.0. The issue was introduced by "[BasicAA] Use MayAlias instead of PartialAlias for fallback."( https://reviews.llvm.org/D34318) I have attached a very simple program to reproduce the issue. The symptom is alias analysis report NoAlias to GVN which cause GVN do wrong optimization. The BasicAA

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, 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

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

Hi, The gpu target I am working on requires the 'value' and 'address' operands of memory store instruction in consecutive register. Anybody has suggestion? - Ruiling -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160909/e9d330bc/attachment.html>

Is it just an optimization pass? Maybe I can cancel it somehow with a flag or by doing some code editing? Can you point me to which passes may do that? I'm working on editing a backend that can't work with anything larger than 32 bits. Does the legalize stage work on IR code? Maybe i can use that? On Jan 29, 2015 5:41 AM, Ruiling Song <ruiling.song83 at gmail.com> wrote: LLVM

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 value is > uniform across a wavefront/warp, otherwise it will be in a vector register. > Does

Folks, Please confirm or correct the following assertions: In Target.td one of the data member fields for class Register is list<string> AltNames. If this is for alternate names for a given register (in Mips $28 and $gp are the same) it would be quite useful for the llvm-mc assembler which has to handle cases where there are multiple names for the same register. A quick recursive grep

On Thu, Apr 02, 2015 at 02:53:26PM -0600, Eric Broch wrote: > On 4/2/2015 1:22 PM, Will Yardley wrote: > > I've been trying to upgrade Dovecot-ee package (on EL6/x86_64) from > > 2.2.15.8-1 to 2.2.16.2-1. It's complaining on these two dependencies: > > > > liblz4.so.1 > > libtextcat.so.0 > > > > These would both seem to be related to plugins,

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 Tue, Sep 6, 2011 at 9:34 PM, Alexandru Dura <alexdura at gmail.com> wrote: > Hi everyone, > > I found some peculiar behavior of TableGen when generating > [TARGET]GenRegisterInfo.inc. Some register overlaps are generated twice in > this file, leading to a compilation error. Hi, What do you mean "overlapped register"? > I think this is because in

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