search for: untyp

Displaying 20 results from an estimated 128 matches for "untyp".

Did you mean: unty
2017 Aug 15
3
How to debug instruction selection
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*, ...)* @_ZN5FooBr7xprintfEPKcz> 0 0x28ec670: i32 = Register %EDI 0x28ec750: i8 = Register %AL 0x28ec360: Untyped...
2012 Dec 05
0
[LLVMdev] [RFC] Replacing EVT:s with MVT:s (when possible)
...chine-specific register types. The only way of doing this involves extending MVT, which requires tweaking three files in the (nominally) target-independent parts of the compiler. It would be great if we could simply reserve a (small?) number of MVTs for target-specific legal values. I added MVT::Untyped a while back to address this kind of use case. You can construct node of MVT::Untyped, and as long as the InstrEmitter can infer what register class they can map to from their uses, everything should just work. Of course, it's only been seriously tested with register sequence (REG_SEQUENCE)...
2013 Apr 06
0
[LLVMdev] [PATCH] RegScavenger::scavengeRegister
...ubregister of the GPRs to hold the data (or maybe 8 bits, and then also use some CR-pair register class)? No, that shouldn't be necessary. The types on register classes are only used by isel, and this register class wouldn't be used before register allocation. Just make it [i32], or even [untyped]. (The type is used to pick a default spill size, so you may need to 'let Size = 4' if you go with untyped). Your implementation in copyPhysReg is the final word on what it means to copy between registers in this class. The register class will not be used automatically without permissio...
2012 Dec 05
2
[LLVMdev] [RFC] Replacing EVT:s with MVT:s (when possible)
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
2010 Sep 26
0
[LLVMdev] LLVM Exception Handling
...;t properly catch the error (ie. throw inside throw, throw inside delete, etc). If that's the case, your implementation will not work for dwarf exceptions, and I wouldn't recommend having an *invoke* syntax for each type of exception handling mechanism. Other question: why are you passing untyped %x? I haven't seen any untyped variable in LLVM, so far, and I think it's good to be redundant in this case. That alone would have caught the mistake. If you need an i32 (for your bad/worse comparison), throwing i8* would have hinted that you crossed the concepts. On a side note... Exc...
2015 Apr 02
2
[LLVMdev] How to enable use of 64bit load/store for 32bit architecture
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[] = { DAG.getTargetConstant(SP::IntPairRegClassID, MVT::i32), DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant(0, MVT::i32)), DAG.getTargetConstant(SP ::sub0, M...
2017 Sep 15
2
Changes to 'ADJCALLSTACK*' and 'callseq_*' between LLVM v4.0 and v5.0
...b8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)* @__assert_func> 0 0x15c9bbd98: ch,glue = MYISD::CALL 0x15c9bbcc8, TargetGlobalAddress:i32<void (i8*, i32, i8*, i8*)* @__assert_func> 0, Register:i32 %I18, Register:i32 %I17, Register:i32 %I16, Register:i32 %I15, RegisterMask:Untyped, 0x15c9bbcc8:1 0x15c9bb8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)* @__assert_func> 0 0x15c9bb9f0: i32 = Register %I18 0x15c9bbac0: i32 = Register %I17 0x15c9bbb90: i32 = Register %I16 0x15c9bbc60: i32 = Register %I15 0x15c9bbd30: Untyped = R...
2013 Apr 06
3
[LLVMdev] [PATCH] RegScavenger::scavengeRegister
----- 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]
2013 Apr 07
1
[LLVMdev] [PATCH] RegScavenger::scavengeRegister
...(or maybe 8 bits, and > > then also use some CR-pair register class)? > > No, that shouldn't be necessary. > > The types on register classes are only used by isel, and this > register class wouldn't be used before register allocation. Just > make it [i32], or even [untyped]. (The type is used to pick a > default spill size, so you may need to 'let Size = 4' if you go with > untyped). > > Your implementation in copyPhysReg is the final word on what it means > to copy between registers in this class. > > The register class will not be u...
2015 Apr 03
2
[LLVMdev] How to enable use of 64bit load/store for 32bit architecture
...>> >> 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[] = { >> DAG.getTargetConstant(SP::IntPairRegClassID, MVT::i32), >> DAG.getNode(ISD::EXTRACT_ELEMENT, dl, MVT::i32, ValueToBeStored, DAG.getConstant...
2013 Mar 21
0
[LLVMdev] Simpler types in TableGen isel patterns
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,
2017 Sep 15
0
Changes to 'ADJCALLSTACK*' and 'callseq_*' between LLVM v4.0 and v5.0
...ddress<void (i8*, i32, i8*, i8*)* > @__assert_func> 0 > 0x15c9bbd98: ch,glue = MYISD::CALL 0x15c9bbcc8, > TargetGlobalAddress:i32<void (i8*, i32, i8*, i8*)* @__assert_func> 0, > Register:i32 %I18, Register:i32 %I17, Register:i32 %I16, Register:i32 %I15, > RegisterMask:Untyped, 0x15c9bbcc8:1 > 0x15c9bb8b8: i32 = TargetGlobalAddress<void (i8*, i32, i8*, i8*)* > @__assert_func> 0 > 0x15c9bb9f0: i32 = Register %I18 > 0x15c9bbac0: i32 = Register %I17 > 0x15c9bbb90: i32 = Register %I16 > 0x15c9bbc60: i32 = Register %I15...
2017 Sep 19
1
Changes to 'ADJCALLSTACK*' and 'callseq_*' between LLVM v4.0 and v5.0
...ss:i32<i32 (i32)* @foo> 0, 0x1ede6ae35e0:1 0x1ede6ae33d8: i32 = TargetConstant<0> 0x1ede6ae3370: i32 = TargetGlobalAddress<i32 (i32)* @foo> 0 0x1ede6ae35e0: ch,glue = MyISD::CALL 0x1ede6ae3510, TargetGlobalAddress:i32<i32 (i32)* @foo> 0, Register:i32 %I18, RegisterMask:Untyped, 0x1ede6ae3510:1 0x1ede6ae3370: i32 = TargetGlobalAddress<i32 (i32)* @foo> 0 0x1ede6ae34a8: i32 = Register %I18 0x1ede6ae3578: Untyped = RegisterMask 0x1ede6ae3510: ch,glue = CopyToReg 0x1ede6ae3440, Register:i32 %I18, Constant:i32<42> 0x1ede6ae34a8: i32 = Regist...
2010 Sep 25
3
[LLVMdev] LLVM Exception Handling
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:
2006 Jan 08
8
I need untyped associations
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
2014 Jul 20
2
[LLVMdev] GHC, aliases, and LLVM HEAD
...as is private. If the alias is > private, then the label never appears in the object file. The alias is > merely a Constant with an internal name. What do you think? Any word on this? As far as I can tell we are stuck on the GHC side until we can alias declarations due to the existence of untyped external references in the C-- representation. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 472 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/201407...
2012 Aug 21
2
[LLVMdev] Passing return values on the stack & storing arbitrary sized integers
> 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 of Mathematics and Mechanics, Saint Petersburg State University
2016 Feb 24
2
[PATCH] D17497: Support arbitrary address space for intrinsics
> 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. > > David +1 The prettiness of intrinsic mangling is irrelevant, especially since this wi...
2014 Dec 11
3
[LLVMdev] [cfe-dev] Phabricator update
...:38 PM, Jonathan Roelofs < >> jonathan at codesourcery.com> wrote: >> >>> I think the send-email part of phab has yet to come back up. >>> >> >> Yes, restarting it would be very helpful. >> > > There was a bug due to a merge-conflict (yay, untyped php code). > Please let me know if you see any further problems. > Thanks & sorry for the inconvenience ... > Thanks for the fix! Looks like now, when Phabricator copies a diff into an email, it inserts extra empty line between every two consecutive diff lines. Could it be caused by...
2017 Feb 14
2
Ensuring chain dependencies with expansion to libcalls
...= callseq_start t0, TargetConstant:i32<0> t47: ch,glue = CopyToReg t46, Register:i64 %reg0, t2 t48: ch,glue = CopyToReg t47, Register:i64 %reg1, t4, t47:1 t50: ch,glue = SHAVEISD::CALL t48, TargetExternalSymbol:i32'__divdi3', Register:i64 %reg0, Register:i64 %reg1, RegisterMask:Untyped, t48:1 t51: ch,glue = callseq_end t50, TargetConstant:i32<0>, TargetExternalSymbol:i32'__divdi3', t50:1 t52: i64,ch,glue = CopyFromReg t51, Register:i64 %reg0, t51:1 t11: ch = CopyToReg t0, Register:i64 %vreg0, t2 t13: ch = CopyToReg t0, Register:i64 %vreg1, t4...