Displaying 20 results from an estimated 118 matches for "is64bits".
Did you mean:
is64bit
2008 Jul 08
3
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi Evan,
Evan Cheng wrote:
> The patch looks great. But I do have one comment:
>
> +let usesCustomDAGSchedInserter = 1 in {
> + let Uses = [CR0] in {
> + let Uses = [R0] in
> + def ATOMIC_LOAD_ADD_I32 : Pseudo<
>
> The "let Uses = [R0]" is not needed. The pseudo instruction will be
> expanded like this later:
>
> + BuildMI(BB,
2014 Mar 13
3
[LLVMdev] Possible bug in getCallPreservedMask for CallingConv::Intel_OCL_BI
Not sure who owns this bit of code, so sending this to the general list.
It looks like there may be an unintentional fall through happening in
the X86RegisterInfo::getCallPreservedMask function.
http://llvm.org/docs/doxygen/html/X86RegisterInfo_8cpp_source.html
case CallingConv::Intel_OCL_BI
2010 Mar 03
0
[LLVMdev] [PATCH] New calling convention for use by GHC
On Mar 2, 2010, at 5:33 PM, David Terei wrote:
> Hi all,
>
> As previously mentioned on this list the Haskell compiler GHC has a new LLVM based back-end. The back-end needs a new calling convention to efficiently use LLVM and that is what this patch does, just for X86 at the moment.
Nice,
> The GHC developers would love to get this included in LLVM so that we don't need to
2010 Mar 07
1
[LLVMdev] [PATCH] New calling convention for use by GHC
OK, new patch attached. Hopefully in time for 2.7.
Chris Lattner wrote:
> 1) is the GHC calling conv intended to be target specific? If it is x86 specific, it should get an X86 prefix. If not, it should move up to be #10 after Cold.
No its intended to be supported on any platforms that GHC is supported
on, which is just x86 and SPARC at the moment. At the moment I've just
done X86, will
2011 Oct 13
0
[LLVMdev] llvm-objdump related patch
...patch according to your suggestion. And I have read
> binutil/objdump source code and found that it has a logic that if there's no
> symtab, it will use dynsym, which is missing in llvm-objdump.
>
> Songmao
>
@@ -747,12 +747,28 @@ error_code ELFObjectFile<target_endianness, is64Bits>
template<support::endianness target_endianness, bool is64Bits>
error_code ELFObjectFile<target_endianness, is64Bits>
::sectionContainsSymbol(DataRefImpl Sec,
DataRefImpl Symb,...
2008 Jul 08
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Look for createVirtualRegister. These are examples in
PPCISelLowering.cpp.
Evan
On Jul 8, 2008, at 8:24 AM, Gary Benson wrote:
> Hi Evan,
>
> Evan Cheng wrote:
>> The patch looks great. But I do have one comment:
>>
>> +let usesCustomDAGSchedInserter = 1 in {
>> + let Uses = [CR0] in {
>> + let Uses = [R0] in
>> + def ATOMIC_LOAD_ADD_I32 :
2011 Oct 12
2
[LLVMdev] llvm-objdump related patch
Michael,
I have rework the patch according to your suggestion. And I have
read binutil/objdump source code and found that it has a logic that if
there's no symtab, it will use dynsym, which is missing in llvm-objdump.
Songmao
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Fix-the-address-calculation-for-llvm-objdump.patch
Type: text/x-patch
2010 Mar 03
2
[LLVMdev] [PATCH] New calling convention for use by GHC
Hi all,
As previously mentioned on this list the Haskell compiler GHC has a new
LLVM based back-end. The back-end needs a new calling convention to
efficiently use LLVM and that is what this patch does, just for X86 at
the moment.
Breakdown:
1) Need actual calling convention
Touches:
- include/llvm/CallingConv.h
- lib/Target/X86/X86CallingConv.td
2) Handling new calling
2003 May 15
2
R as 64 bit application
In a package test I have a problem that needs over 4G of memory. This requires
that I use R compiled as a 64 bit application. Is there a way within R to test
if R has been compile as a 64 bit application? This would allow me to
automatically skip the test when I know it is going to fail.
Thanks,
Paul Gilbert
2003 May 15
2
R as 64 bit application
In a package test I have a problem that needs over 4G of memory. This requires
that I use R compiled as a 64 bit application. Is there a way within R to test
if R has been compile as a 64 bit application? This would allow me to
automatically skip the test when I know it is going to fail.
Thanks,
Paul Gilbert
2008 Jul 04
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi Gary,
The patch looks great. But I do have one comment:
+let usesCustomDAGSchedInserter = 1 in {
+ let Uses = [CR0] in {
+ let Uses = [R0] in
+ def ATOMIC_LOAD_ADD_I32 : Pseudo<
The "let Uses = [R0]" is not needed. The pseudo instruction will be
expanded like this later:
+ BuildMI(BB, TII->get(is64bit ? PPC::LDARX : PPC::LWARX), dest)
+
2008 Jul 10
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Evan Cheng wrote:
> How about?
>
> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass :
> &PPC:G8RCRegClass;
> unsigned TmpReg = RegInfo.createVirtualRegister(RC);
I tried something like that yesterday:
const TargetRegisterClass *RC =
is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass;
but I kept getting this error no matter how I arranged it:
2008 Jul 10
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Just cast both values to const TargetRegisterClass*.
Evan
On Jul 10, 2008, at 7:36 AM, Gary Benson wrote:
> Evan Cheng wrote:
>> How about?
>>
>> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass :
>> &PPC:G8RCRegClass;
>> unsigned TmpReg = RegInfo.createVirtualRegister(RC);
>
> I tried something like that yesterday:
>
> const
2008 Jul 10
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Cool, that worked. New patch attached...
Cheers,
Gary
Evan Cheng wrote:
> Just cast both values to const TargetRegisterClass*.
>
> Evan
>
> On Jul 10, 2008, at 7:36 AM, Gary Benson wrote:
> > Evan Cheng wrote:
> > > How about?
> > >
> > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass :
> > > &PPC:G8RCRegClass;
>
2008 Jul 02
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Evan Cheng wrote:
> You need to insert new basic blocks and update CFG to accomplish this.
> There is a hackish way to do this right now. Add a pseudo instruction
> to represent this operation and mark it usesCustomDAGSchedInserter.
> This means the intrinsic is mapped to a single (pseudo) node. But it
> is then expanded into instructions that can span multiple basic
>
2008 Jul 09
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Ah, didn't see that, that's what comes of trying to do something at
5pm :) I attached an updated patch which creates a virtual register
instead of using R0. How does this look?
Cheers,
Gary
Dan Gohman wrote:
> PPCTargetLowering::EmitInstrWithCustomInserter has a reference
> to the current MachineFunction for other purposes. Can you use
> MachineFunction::getRegInfo instead?
2008 Jul 08
2
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Would it be acceptable to change MachineInstr::getRegInfo from private
to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter?
Cheers,
Gary
Evan Cheng wrote:
> Look for createVirtualRegister. These are examples in
> PPCISelLowering.cpp.
>
> Evan
> On Jul 8, 2008, at 8:24 AM, Gary Benson wrote:
>
> > Hi Evan,
> >
> > Evan Cheng wrote:
2008 Jul 11
0
[LLVMdev] Implementing llvm.atomic.cmp.swap.i32 on PowerPC
Hi Gary,
This does not patch cleanly for me (PPCISelLowering.cpp). Can you
prepare a updated patch?
Thanks,
Evan
On Jul 10, 2008, at 11:45 AM, Gary Benson wrote:
> Cool, that worked. New patch attached...
>
> Cheers,
> Gary
>
> Evan Cheng wrote:
>> Just cast both values to const TargetRegisterClass*.
>>
>> Evan
>>
>> On Jul 10, 2008, at 7:36
2008 Mar 27
0
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
Does this fix it?
Index: lib/Target/X86/X86Subtarget.h
===================================================================
--- lib/Target/X86/X86Subtarget.h (revision 48879)
+++ lib/Target/X86/X86Subtarget.h (working copy)
@@ -144,9 +144,12 @@
std::string getDataLayout() const {
const char *p;
- if (is64Bit())
- p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128";
-
2008 Mar 27
1
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
Probably better to move the discussion to a bug?
Evan
On Mar 27, 2008, at 9:04 AM, Duncan Sands wrote:
> Does this fix it?
>
> Index: lib/Target/X86/X86Subtarget.h
> ===================================================================
> --- lib/Target/X86/X86Subtarget.h (revision 48879)
> +++ lib/Target/X86/X86Subtarget.h (working copy)
> @@ -144,9 +144,12 @@
>
>