search for: untypical

Hi there, I try to JIT compile some bitcode and seeing the following error: LLVM ERROR: Cannot select: 0x28ec830: ch,glue = X86ISD::CALL 0x28ec7c0, 0x28ef900, Register:i32 %EDI, Register:i8 %AL, RegisterMask:Untyped, 0x28ec7c0:1 0x28ef900: i32 = X86ISD::Wrapper TargetGlobalAddress:i32<void (i8*, ...)* @_ZN5FooBr7xprintfEPKcz> 0 0x28ec520: i32 = TargetGlobalAddress<void (i8*, ...)*

On Dec 5, 2012, at 4:51 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 3 Dec 2012, at 23:45, Chris Lattner wrote: > >> Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code generator that are "pre-legalization" because they can represent arbitrary IR types.

On Apr 6, 2013, at 12:42 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> >> To: "Akira Hatanaka" <ahatanak at gmail.com> >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> >>

On 3 Dec 2012, at 23:45, Chris Lattner wrote: > Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code generator that are "pre-legalization" because they can represent arbitrary IR types. Anything that takes a legal machine type should take an MVT. A side issue of this is that it is

On 25 September 2010 23:46, Nathan Jeffords <blunted2night at gmail.com> wrote: > catch: >   %v = ptrtoint i8 * %x to i32 >   %r = icmp eq i32 %v, 255 >   br i1 %r, label %bad, label %worse > bad: >   ret i32 -1 > worse: >   ret i32 -2 > } If I understood correctly, you're trying to pass the clean-up flag through %x directly on the invoke call. But later avoid

Hi James, Jim If you *really* want this to work in selection DAG then there is a solution, but its not pretty. First make i64 not be legal. Then, assuming the regclass you gave has some subregs, you can give load/store a custom legalisation where you change the i64 to MVT::Untyped. So something like this for ISD::STORE: SDValue ValueToBeStored = St.getOperand(…) auto SeqOps[] = {

Hi LLVM-Devs, I have managed to complete updating our sources from LLVM v4.0 to v5.0, but I am getting selection errors for 'callseq_end'. I am aware that the 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have added an additional argument to the TD descriptions for these. There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG',

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Tuesday, March 26, 2013 12:40:44 PM > Subject: Re: [LLVMdev] [PATCH]

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Akira Hatanaka" <ahatanak at gmail.com> > Sent: Saturday, April 6, 2013 11:56:28 AM > Subject: Re: [LLVMdev] [PATCH]

> On Apr 2, 2015, at 2:07 PM, Tom Stellard <tom at stellard.net> wrote: > > On Thu, Apr 02, 2015 at 01:35:55PM -0700, Pete Cooper wrote: >> Hi James, Jim >> >> If you *really* want this to work in selection DAG then there is a solution, but its not pretty. >> >> First make i64 not be legal. Then, assuming the regclass you gave has some subregs, you

On Mar 21, 2013, at 11:26 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I think in most cases it would be much simpler and safer to specify pattern types directly: > > def : Pat<(and (not i32:$src1), i32:$src2), > (ANDN32rr i32:$src1, i32:$src2)>; > def : Pat<(and (not i64:$src1), i64:$src2), > (ANDN64rr i64:$src1,

Hi Martin, Pseudo CALLSEQ_START was changed in r302527, commit message contains details on the changes. However CALLSEQ_END was not modified. If your made changes to ADJCALLSTACKUP to add additional argument, that may result in error. Thanks, --Serge 2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org>: > Hi LLVM-Devs, > > I have managed

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

Hi guys, I have begun a modification to the invoke/unwind instructions. The following .ll file demonstrates the change. define i32 @v(i32 %o) { %r = icmp eq i32 %o, 0 br i1 %r, label %raise, label %ok ok: %m = mul i32 %o, 2 ret i32 %m raise: %ex = inttoptr i32 255 to i8 * ; unwind now takes an i8* "exception" pointer unwind i8* %ex } define i32 @g(i32 %o) { entry:

I am in the process of trying to migrate to ROR from a home grown ORM, but one stumbling block is ActiveRecord''s typed associations and object ID assignment scheme. In the home grown system, I have a master table which *all* objects are packed into and a master associative table which holds *all* associations. This allows each object, regardless of type, to have a unique ID and thus it

Reid Kleckner <rnk at google.com> writes: > On Tue, Jun 3, 2014 at 1:29 PM, Rafael Espíndola <rafael.espindola at gmail.com >> wrote: > >> > It looks fairly likely llvm will accept arbitrary expressions as >> > aliasees again (see thread on llvmdev), but the restrictions inherent >> > from what alias are at the object level will remain, just be

> This isn't really my area of expertise, but I think you're messing up > your RegisterClass definition. Look at how ARM defines DTriple. DTriple is untyped :) , because we do not have any valut type which defines 3xi64. However, the paired register needs to have type. Fabian, what are the definitions of ER and DR register classes? -- With best regards, Anton Korobeynikov Faculty

> On Feb 24, 2016, at 09:32, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > My gut feeling is that it’s not worth it. When we move from typed to untyped pointers, we’re going to change the mangling from something like p200i8 to just p200, which is already quite a bit cleaner, and actually looks cleaner to me than the version proposed in this patch. > >

On Thu, Dec 11, 2014 at 1:29 AM, Manuel Klimek <klimek at google.com> wrote: > On Thu Dec 11 2014 at 2:16:00 AM Alexey Samsonov <vonosmas at gmail.com> > wrote: > >> On Wed, Dec 10, 2014 at 2:38 PM, Jonathan Roelofs < >> jonathan at codesourcery.com> wrote: >> >>> I think the send-email part of phab has yet to come back up. >>>

Hi all, Our target does not have native support for 64-bit integers, so we rely on library calls for certain operations (like sdiv). We recently ran into a problem where these operations that are expanded to library calls aren't maintaining the proper ordering in relation to other chains in the DAG. The following snippet of a DAG demonstrates the problem. t0: ch = EntryToken t2: