[llvm-commits] [llvm] r42433 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h test/CodeGen/X86/memcpy.ll
Author: rafael
Date: Fri Sep 28 07:53:01 2007
New Revision: 42433
URL: http://llvm.org/viewvc/llvm-project?rev=42433&view=rev
Log:
Refactor the memcpy lowering for the x86 target.
The only generated code difference is that now we call memcpy when
the size of the array is unknown. This matches GCC behavior and is
better since the run time value can be arbitrarily large.
Added:
llvm/trunk/test/CodeGen/X86/memcpy.ll
Modified:
llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
llvm/trunk/lib/Target/X86/X86ISelLowering.h
Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=42433&r1=42432&r2=42433&view=diff
==
--- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original)
+++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Fri Sep 28 07:53:01 2007
@@ -4188,35 +4188,61 @@
}
SDOperand X86TargetLowering::LowerMEMCPY(SDOperand Op, SelectionDAG &DAG) {
- SDOperand Chain = Op.getOperand(0);
- unsigned Align =
-(unsigned)cast(Op.getOperand(4))->getValue();
+ SDOperand ChainOp = Op.getOperand(0);
+ SDOperand DestOp = Op.getOperand(1);
+ SDOperand SourceOp = Op.getOperand(2);
+ SDOperand CountOp = Op.getOperand(3);
+ SDOperand AlignOp = Op.getOperand(4);
+ unsigned Align = (unsigned)cast(AlignOp)->getValue();
if (Align == 0) Align = 1;
- ConstantSDNode *I = dyn_cast(Op.getOperand(3));
- // If not DWORD aligned or size is more than the threshold, call memcpy.
- // The libc version is likely to be faster for these cases. It can use the
- // address value and run time information about the CPU.
+ // The libc version is likely to be faster for the following cases. It can
+ // use the address value and run time information about the CPU.
// With glibc 2.6.1 on a core 2, coping an array of 100M longs was 30% faster
- if ((Align & 3) != 0 ||
- (I && I->getValue() > Subtarget->getMinRepStrSizeThreshold())) {
-MVT::ValueType IntPtr = getPointerTy();
-TargetLowering::ArgListTy Args;
-TargetLowering::ArgListEntry Entry;
-Entry.Ty = getTargetData()->getIntPtrType();
-Entry.Node = Op.getOperand(1); Args.push_back(Entry);
-Entry.Node = Op.getOperand(2); Args.push_back(Entry);
-Entry.Node = Op.getOperand(3); Args.push_back(Entry);
-std::pair CallResult =
+
+ // If not DWORD aligned, call memcpy.
+ if ((Align & 3) != 0)
+return LowerMEMCPYCall(ChainOp, DestOp, SourceOp, CountOp, DAG);
+
+ // If size is unknown, call memcpy.
+ ConstantSDNode *I = dyn_cast(CountOp);
+ if (!I)
+return LowerMEMCPYCall(ChainOp, DestOp, SourceOp, CountOp, DAG);
+
+ // If size is more than the threshold, call memcpy.
+ unsigned Size = I->getValue();
+ if (Size > Subtarget->getMinRepStrSizeThreshold())
+return LowerMEMCPYCall(ChainOp, DestOp, SourceOp, CountOp, DAG);
+
+ return LowerMEMCPYInline(ChainOp, DestOp, SourceOp, Size, Align, DAG);
+}
+
+SDOperand X86TargetLowering::LowerMEMCPYCall(SDOperand Chain,
+ SDOperand Dest,
+ SDOperand Source,
+ SDOperand Count,
+ SelectionDAG &DAG) {
+ MVT::ValueType IntPtr = getPointerTy();
+ TargetLowering::ArgListTy Args;
+ TargetLowering::ArgListEntry Entry;
+ Entry.Ty = getTargetData()->getIntPtrType();
+ Entry.Node = Dest; Args.push_back(Entry);
+ Entry.Node = Source; Args.push_back(Entry);
+ Entry.Node = Count; Args.push_back(Entry);
+ std::pair CallResult =
LowerCallTo(Chain, Type::VoidTy, false, false, CallingConv::C, false,
DAG.getExternalSymbol("memcpy", IntPtr), Args, DAG);
-return CallResult.second;
- }
+ return CallResult.second;
+}
+SDOperand X86TargetLowering::LowerMEMCPYInline(SDOperand Chain,
+ SDOperand Dest,
+ SDOperand Source,
+ unsigned Size,
+ unsigned Align,
+ SelectionDAG &DAG) {
MVT::ValueType AVT;
- SDOperand Count;
unsigned BytesLeft = 0;
- bool TwoRepMovs = false;
switch (Align & 3) {
case 2: // WORD aligned
AVT = MVT::i16;
@@ -4228,33 +4254,22 @@
break;
default: // Byte aligned
AVT = MVT::i8;
- Count = Op.getOperand(3);
break;
}
- if (AVT > MVT::i8) {
-if (I) {
- unsigned UBytes = MVT::getSizeInBits(AVT) / 8;
- Count = DAG.getConstant(I->getValue() / UBytes, getPointerTy());
- BytesLeft = I->getValue() % UBytes;
-} else {
- assert(AVT >= MVT::i32 &&
- "Do not use rep;movs if not at least DWORD aligned");
- Count = DAG.getNode(ISD::SRL, Op.getOperand(3).getValueType(),
-
[llvm-commits] [llvm] r42434 - /llvm/trunk/lib/CodeGen/DwarfWriter.cpp
Author: djg
Date: Fri Sep 28 10:43:33 2007
New Revision: 42434
URL: http://llvm.org/viewvc/llvm-project?rev=42434&view=rev
Log:
Use 32-bit data directives for DW_FORM_data4 format data, even on
targets with 64-bit addresses.
Modified:
llvm/trunk/lib/CodeGen/DwarfWriter.cpp
Modified: llvm/trunk/lib/CodeGen/DwarfWriter.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/DwarfWriter.cpp?rev=42434&r1=42433&r2=42434&view=diff
==
--- llvm/trunk/lib/CodeGen/DwarfWriter.cpp (original)
+++ llvm/trunk/lib/CodeGen/DwarfWriter.cpp Fri Sep 28 10:43:33 2007
@@ -870,18 +870,20 @@
/// EmitReference - Emit a reference to a label.
///
- void EmitReference(DWLabel Label, bool IsPCRelative = false) const {
-EmitReference(Label.Tag, Label.Number, IsPCRelative);
+ void EmitReference(DWLabel Label, bool IsPCRelative = false,
+ bool Force32Bit = false) const {
+EmitReference(Label.Tag, Label.Number, IsPCRelative, Force32Bit);
}
void EmitReference(const char *Tag, unsigned Number,
- bool IsPCRelative = false) const {
-PrintRelDirective();
+ bool IsPCRelative = false, bool Force32Bit = false) const
{
+PrintRelDirective(Force32Bit);
PrintLabelName(Tag, Number);
if (IsPCRelative) O << "-" << TAI->getPCSymbol();
}
- void EmitReference(const std::string &Name, bool IsPCRelative = false) const
{
-PrintRelDirective();
+ void EmitReference(const std::string &Name, bool IsPCRelative = false,
+ bool Force32Bit = false) const {
+PrintRelDirective(Force32Bit);
O << Name;
@@ -3479,7 +3481,7 @@
/// EmitValue - Emit label value.
///
void DIEDwarfLabel::EmitValue(DwarfDebug &DD, unsigned Form) {
- DD.EmitReference(Label);
+ DD.EmitReference(Label, false, Form == DW_FORM_data4);
}
/// SizeOf - Determine size of label value in bytes.
@@ -3493,7 +3495,7 @@
/// EmitValue - Emit label value.
///
void DIEObjectLabel::EmitValue(DwarfDebug &DD, unsigned Form) {
- DD.EmitReference(Label);
+ DD.EmitReference(Label, false, Form == DW_FORM_data4);
}
/// SizeOf - Determine size of label value in bytes.
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42433 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h test/CodeGen/X86/memcpy.ll
Hi Rafael,
Are you sure this is better? Did you do any measurement? Our goal
isn't to match gcc output. :)
Perhaps you can add some unit tests to llvm-test?
Thanks,
Evan
On Sep 28, 2007, at 5:53 AM, Rafael Espindola <[EMAIL PROTECTED]
> wrote:
> Author: rafael
> Date: Fri Sep 28 07:53:01 2007
> New Revision: 42433
>
> URL: http://llvm.org/viewvc/llvm-project?rev=42433&view=rev
> Log:
> Refactor the memcpy lowering for the x86 target.
>
> The only generated code difference is that now we call memcpy when
> the size of the array is unknown. This matches GCC behavior and is
> better since the run time value can be arbitrarily large.
>
>
> Added:
>llvm/trunk/test/CodeGen/X86/memcpy.ll
> Modified:
>llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
>llvm/trunk/lib/Target/X86/X86ISelLowering.h
>
> Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=42433&r1=42432&r2=42433&view=diff
>
> ===
> ===
> ===
> =
> --- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original)
> +++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Fri Sep 28
> 07:53:01 2007
> @@ -4188,35 +4188,61 @@
> }
>
> SDOperand X86TargetLowering::LowerMEMCPY(SDOperand Op, SelectionDAG
> &DAG) {
> - SDOperand Chain = Op.getOperand(0);
> - unsigned Align =
> -(unsigned)cast(Op.getOperand(4))->getValue();
> + SDOperand ChainOp = Op.getOperand(0);
> + SDOperand DestOp = Op.getOperand(1);
> + SDOperand SourceOp = Op.getOperand(2);
> + SDOperand CountOp = Op.getOperand(3);
> + SDOperand AlignOp = Op.getOperand(4);
> + unsigned Align = (unsigned)cast(AlignOp)->getValue
> ();
> if (Align == 0) Align = 1;
>
> - ConstantSDNode *I = dyn_cast(Op.getOperand(3));
> - // If not DWORD aligned or size is more than the threshold, call
> memcpy.
> - // The libc version is likely to be faster for these cases. It
> can use the
> - // address value and run time information about the CPU.
> + // The libc version is likely to be faster for the following
> cases. It can
> + // use the address value and run time information about the CPU.
> // With glibc 2.6.1 on a core 2, coping an array of 100M longs was
> 30% faster
> - if ((Align & 3) != 0 ||
> - (I && I->getValue() > Subtarget->getMinRepStrSizeThreshold
> ())) {
> -MVT::ValueType IntPtr = getPointerTy();
> -TargetLowering::ArgListTy Args;
> -TargetLowering::ArgListEntry Entry;
> -Entry.Ty = getTargetData()->getIntPtrType();
> -Entry.Node = Op.getOperand(1); Args.push_back(Entry);
> -Entry.Node = Op.getOperand(2); Args.push_back(Entry);
> -Entry.Node = Op.getOperand(3); Args.push_back(Entry);
> -std::pair CallResult =
> +
> + // If not DWORD aligned, call memcpy.
> + if ((Align & 3) != 0)
> +return LowerMEMCPYCall(ChainOp, DestOp, SourceOp, CountOp, DAG);
> +
> + // If size is unknown, call memcpy.
> + ConstantSDNode *I = dyn_cast(CountOp);
> + if (!I)
> +return LowerMEMCPYCall(ChainOp, DestOp, SourceOp, CountOp, DAG);
> +
> + // If size is more than the threshold, call memcpy.
> + unsigned Size = I->getValue();
> + if (Size > Subtarget->getMinRepStrSizeThreshold())
> +return LowerMEMCPYCall(ChainOp, DestOp, SourceOp, CountOp, DAG);
> +
> + return LowerMEMCPYInline(ChainOp, DestOp, SourceOp, Size, Align,
> DAG);
> +}
> +
> +SDOperand X86TargetLowering::LowerMEMCPYCall(SDOperand Chain,
> + SDOperand Dest,
> + SDOperand Source,
> + SDOperand Count,
> + SelectionDAG &DAG) {
> + MVT::ValueType IntPtr = getPointerTy();
> + TargetLowering::ArgListTy Args;
> + TargetLowering::ArgListEntry Entry;
> + Entry.Ty = getTargetData()->getIntPtrType();
> + Entry.Node = Dest; Args.push_back(Entry);
> + Entry.Node = Source; Args.push_back(Entry);
> + Entry.Node = Count; Args.push_back(Entry);
> + std::pair CallResult =
> LowerCallTo(Chain, Type::VoidTy, false, false, CallingConv::C,
> false,
> DAG.getExternalSymbol("memcpy", IntPtr), Args, DAG);
> -return CallResult.second;
> - }
> + return CallResult.second;
> +}
>
> +SDOperand X86TargetLowering::LowerMEMCPYInline(SDOperand Chain,
> + SDOperand Dest,
> + SDOperand Source,
> + unsigned Size,
> + unsigned Align,
> + SelectionDAG &DAG) {
> MVT::ValueType AVT;
> - SDOperand Count;
> unsigned BytesLeft = 0;
> - bool TwoRepMovs = false;
> switch (Align & 3) {
> case 2: // WORD aligned
> AVT = MVT::i16;
> @@ -4228,33 +4254,22 @@
> break;
> default: /
Re: [llvm-commits] [llvm] r42423 - in /llvm/trunk: include/llvm/CodeGen/RuntimeLibcalls.h include/llvm/Intrinsics.td lib/Analysis/ConstantFolding.cpp lib/CodeGen/SelectionDAG/LegalizeDAG.cpp lib/CodeG
On Sep 28, 2007, at 10:00 AM, Chris Lattner wrote: > Hi Dale, >> >>def int_powi_f32 : Intrinsic<[llvm_float_ty, llvm_float_ty, >> llvm_i32_ty]>; >>def int_powi_f64 : Intrinsic<[llvm_double_ty, llvm_double_ty, >> llvm_i32_ty]>; >> + def int_powi_f80 : Intrinsic<[llvm_f80_ty, llvm_f80_ty, >> llvm_i32_ty]>; >> + def int_powi_f128 : Intrinsic<[llvm_f128_ty, llvm_f128_ty, >> llvm_i32_ty]>; >> + def int_powi_ppcf128 : Intrinsic<[llvm_ppcf128_ty, >> llvm_ppcf128_ty, >> +llvm_i32_ty]>; >> } > > Why not use anyfp? This would allow us to have one sqrt and one powi > definition. Hard to explain; it just feels like the sort of thing where all the values ought to be spelled out. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm-www/releases/index.html
Changes in directory llvm-www/releases: index.html updated: 1.40 -> 1.41 --- Log message: fix link --- Diffs of the changes: (+1 -1) index.html |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm-www/releases/index.html diff -u llvm-www/releases/index.html:1.40 llvm-www/releases/index.html:1.41 --- llvm-www/releases/index.html:1.40 Fri Sep 28 10:41:38 2007 +++ llvm-www/releases/index.htmlFri Sep 28 10:42:04 2007 @@ -76,7 +76,7 @@ http://llvm.org/docs/";>Current LLVM SVN HEAD documentation -Documentation for LLVM 2.0 +Documentation for LLVM 2.1 Documentation for LLVM 2.0 Documentation for LLVM 1.9 Documentation for LLVM 1.8 ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42285 - in /llvm/trunk/lib/Target/X86: X86FloatingPoint.cpp X86ISelLowering.cpp X86ISelLowering.h X86InstrFPStack.td X86InstrInfo.cpp X86InstrInfo.td X86InstrSSE.td X86Instr
>>> +def X86cmp_new : SDNode<"X86ISD::CMP_NEW" , SDTX86CmpTest>; >> >> X86ISD::CMP_NEW SelectionDAG nodes return an i32 flags value, >> however the >> corresponding X86cmp_new pattern-matching nodes use SDTX86CmpTest, >> which has >> no result values. Is this intentional? If so, how is the discrepancy >> handled? > > X86ISD::CMP_NEW does *not* return an flag result. It returns an result > in a physical register EFLAGS. It's up to the scheduler to ensure > nothing that can potentially modify EFLAGS is scheduled between > CMP_NEW and its users. The goal of what I've been doing is to > eliminate the need for the MVT::Flag hackery (which prevents SDNode > CSE, scheduling, etc.). It returns an MVT::i32 flags result, rather than an MVT::Flag flags result. Or at least, that's how I interpreted this code in X86ISelLowering.cpp: Cond = DAG.getNode(X86ISD::CMP_NEW, MVT::i32, Op0, Op1); Now, X86InstrInfo.td has the following: def SDTX86CmpTest : SDTypeProfile<0, 2, [SDTCisSameAs<0, 1>]>; def X86cmp_new : SDNode<"X86ISD::CMP_NEW" , SDTX86CmpTest>; At an initial glance, these are inconsistent. Does the let Defs = [EFLAGS] around each of the instructions that uses X86cmp_new automatically get used for the result value of a node? That doesn't appear to be the case in other instruction patterns that have implicit defs. >>> +def : Pat<(parallel (X86cmp_new GR8:$src1, 0), (implicit EFLAGS)), >>> + (NEW_TEST8rr GR8:$src1, GR8:$src1)>; >> >> In the SelectionDAG IR, an SDNode can return multiple results. >> However, in >> this GCC-RTL-like pattern langauge, where many things are supposed >> to directly >> correspond to SelectionDAG counterparts, nodes can return at most >> one result. >> They must be grouped together in a parallel to represent operations >> that have >> multiple results. It seems like this will result in more >> discrepancies. Am I >> misunderstanding something? > > Again, no discrepancies. Instruction NEW_TEST8rr produces an implicit > result in EFLAGS. What the pattern is saying is the target independent > node expects the implicit result EFLAGS to be modeled as an explicit > result. > > BTW, I intend to get rid of "parallel". I just haven't gotten around > to it. Ok, cool. I'll take a closer look at this when it's ready. Dan -- Dan Gohman, Cray Inc. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42433 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h test/CodeGen/X86/memcpy.ll
On Sep 28, 2007, at 8:36 AM, Evan Cheng wrote:
> Are you sure this is better? Did you do any measurement? Our goal
> isn't to match gcc output. :)
I think this behavior makes sense. If the size is variable, it could
be arbitrarily large. We should assume that memcpy (the library
implementation) is tuned as best as possible for handling the unknown
size case.
-Chris
> Perhaps you can add some unit tests to llvm-test?
>
> Thanks,
>
> Evan
>
> On Sep 28, 2007, at 5:53 AM, Rafael Espindola
> <[EMAIL PROTECTED]
>> wrote:
>
>> Author: rafael
>> Date: Fri Sep 28 07:53:01 2007
>> New Revision: 42433
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=42433&view=rev
>> Log:
>> Refactor the memcpy lowering for the x86 target.
>>
>> The only generated code difference is that now we call memcpy when
>> the size of the array is unknown. This matches GCC behavior and is
>> better since the run time value can be arbitrarily large.
>>
>>
>> Added:
>>llvm/trunk/test/CodeGen/X86/memcpy.ll
>> Modified:
>>llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
>>llvm/trunk/lib/Target/X86/X86ISelLowering.h
>>
>> Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/
>> X86ISelLowering.cpp?rev=42433&r1=42432&r2=42433&view=diff
>>
>> ===
>> ===
>> ===
>> =
>> --- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original)
>> +++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Fri Sep 28
>> 07:53:01 2007
>> @@ -4188,35 +4188,61 @@
>> }
>>
>> SDOperand X86TargetLowering::LowerMEMCPY(SDOperand Op, SelectionDAG
>> &DAG) {
>> - SDOperand Chain = Op.getOperand(0);
>> - unsigned Align =
>> -(unsigned)cast(Op.getOperand(4))->getValue();
>> + SDOperand ChainOp = Op.getOperand(0);
>> + SDOperand DestOp = Op.getOperand(1);
>> + SDOperand SourceOp = Op.getOperand(2);
>> + SDOperand CountOp = Op.getOperand(3);
>> + SDOperand AlignOp = Op.getOperand(4);
>> + unsigned Align = (unsigned)cast(AlignOp)->getValue
>> ();
>> if (Align == 0) Align = 1;
>>
>> - ConstantSDNode *I = dyn_cast(Op.getOperand(3));
>> - // If not DWORD aligned or size is more than the threshold, call
>> memcpy.
>> - // The libc version is likely to be faster for these cases. It
>> can use the
>> - // address value and run time information about the CPU.
>> + // The libc version is likely to be faster for the following
>> cases. It can
>> + // use the address value and run time information about the CPU.
>> // With glibc 2.6.1 on a core 2, coping an array of 100M longs was
>> 30% faster
>> - if ((Align & 3) != 0 ||
>> - (I && I->getValue() > Subtarget->getMinRepStrSizeThreshold
>> ())) {
>> -MVT::ValueType IntPtr = getPointerTy();
>> -TargetLowering::ArgListTy Args;
>> -TargetLowering::ArgListEntry Entry;
>> -Entry.Ty = getTargetData()->getIntPtrType();
>> -Entry.Node = Op.getOperand(1); Args.push_back(Entry);
>> -Entry.Node = Op.getOperand(2); Args.push_back(Entry);
>> -Entry.Node = Op.getOperand(3); Args.push_back(Entry);
>> -std::pair CallResult =
>> +
>> + // If not DWORD aligned, call memcpy.
>> + if ((Align & 3) != 0)
>> +return LowerMEMCPYCall(ChainOp, DestOp, SourceOp, CountOp, DAG);
>> +
>> + // If size is unknown, call memcpy.
>> + ConstantSDNode *I = dyn_cast(CountOp);
>> + if (!I)
>> +return LowerMEMCPYCall(ChainOp, DestOp, SourceOp, CountOp, DAG);
>> +
>> + // If size is more than the threshold, call memcpy.
>> + unsigned Size = I->getValue();
>> + if (Size > Subtarget->getMinRepStrSizeThreshold())
>> +return LowerMEMCPYCall(ChainOp, DestOp, SourceOp, CountOp, DAG);
>> +
>> + return LowerMEMCPYInline(ChainOp, DestOp, SourceOp, Size, Align,
>> DAG);
>> +}
>> +
>> +SDOperand X86TargetLowering::LowerMEMCPYCall(SDOperand Chain,
>> + SDOperand Dest,
>> + SDOperand Source,
>> + SDOperand Count,
>> + SelectionDAG &DAG) {
>> + MVT::ValueType IntPtr = getPointerTy();
>> + TargetLowering::ArgListTy Args;
>> + TargetLowering::ArgListEntry Entry;
>> + Entry.Ty = getTargetData()->getIntPtrType();
>> + Entry.Node = Dest; Args.push_back(Entry);
>> + Entry.Node = Source; Args.push_back(Entry);
>> + Entry.Node = Count; Args.push_back(Entry);
>> + std::pair CallResult =
>> LowerCallTo(Chain, Type::VoidTy, false, false, CallingConv::C,
>> false,
>> DAG.getExternalSymbol("memcpy", IntPtr), Args,
>> DAG);
>> -return CallResult.second;
>> - }
>> + return CallResult.second;
>> +}
>>
>> +SDOperand X86TargetLowering::LowerMEMCPYInline(SDOperand Chain,
>> + SDOperand Dest,
>> + SDOperand Source,
>> + unsigned Size,
Re: [llvm-commits] [llvm] r42423 - in /llvm/trunk: include/llvm/CodeGen/RuntimeLibcalls.h include/llvm/Intrinsics.td lib/Analysis/ConstantFolding.cpp lib/CodeGen/SelectionDAG/LegalizeDAG.cpp lib/CodeG
Hi Dale,
On Sep 27, 2007, at 6:08 PM, Dale Johannesen wrote:
> ==
>
> --- llvm/trunk/include/llvm/Intrinsics.td (original)
> +++ llvm/trunk/include/llvm/Intrinsics.td Thu Sep 27 20:08:20 2007
> @@ -76,6 +76,9 @@
> def llvm_i64_ty: LLVMType;
> def llvm_float_ty : LLVMType;
> def llvm_double_ty : LLVMType;
> +def llvm_f80_ty: LLVMType;
> +def llvm_f128_ty : LLVMType;
> +def llvm_ppcf128_ty: LLVMType;
> def llvm_ptr_ty:
> LLVMPointerType; // i8*
> def llvm_ptrptr_ty :
> LLVMPointerType;// i8**
> def llvm_empty_ty :
> LLVMType; // { }
> @@ -177,9 +180,16 @@
> let Properties = [IntrNoMem] in {
>def int_sqrt_f32 : Intrinsic<[llvm_float_ty, llvm_float_ty]>;
>def int_sqrt_f64 : Intrinsic<[llvm_double_ty, llvm_double_ty]>;
> + def int_sqrt_f80 : Intrinsic<[llvm_f80_ty, llvm_f80_ty]>;
> + def int_sqrt_f128 : Intrinsic<[llvm_f128_ty, llvm_f128_ty]>;
> + def int_sqrt_ppcf128 : Intrinsic<[llvm_ppcf128_ty,
> llvm_ppcf128_ty]>;
>
>def int_powi_f32 : Intrinsic<[llvm_float_ty, llvm_float_ty,
> llvm_i32_ty]>;
>def int_powi_f64 : Intrinsic<[llvm_double_ty, llvm_double_ty,
> llvm_i32_ty]>;
> + def int_powi_f80 : Intrinsic<[llvm_f80_ty, llvm_f80_ty,
> llvm_i32_ty]>;
> + def int_powi_f128 : Intrinsic<[llvm_f128_ty, llvm_f128_ty,
> llvm_i32_ty]>;
> + def int_powi_ppcf128 : Intrinsic<[llvm_ppcf128_ty, llvm_ppcf128_ty,
> +llvm_i32_ty]>;
> }
Why not use anyfp? This would allow us to have one sqrt and one powi
definition.
-Chris
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42435 - /llvm/trunk/lib/CodeGen/DwarfWriter.cpp
Author: djg
Date: Fri Sep 28 11:50:28 2007
New Revision: 42435
URL: http://llvm.org/viewvc/llvm-project?rev=42435&view=rev
Log:
Make the checks for DW_FORM_data4 consistent with the others, and
add more such code for DIEDwarfLabel::SizeOf and DIEObjectLabel::SizeOf.
Modified:
llvm/trunk/lib/CodeGen/DwarfWriter.cpp
Modified: llvm/trunk/lib/CodeGen/DwarfWriter.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/DwarfWriter.cpp?rev=42435&r1=42434&r2=42435&view=diff
==
--- llvm/trunk/lib/CodeGen/DwarfWriter.cpp (original)
+++ llvm/trunk/lib/CodeGen/DwarfWriter.cpp Fri Sep 28 11:50:28 2007
@@ -3481,12 +3481,14 @@
/// EmitValue - Emit label value.
///
void DIEDwarfLabel::EmitValue(DwarfDebug &DD, unsigned Form) {
- DD.EmitReference(Label, false, Form == DW_FORM_data4);
+ bool IsSmall = Form == DW_FORM_data4;
+ DD.EmitReference(Label, false, IsSmall);
}
/// SizeOf - Determine size of label value in bytes.
///
unsigned DIEDwarfLabel::SizeOf(const DwarfDebug &DD, unsigned Form) const {
+ if (Form == DW_FORM_data4) return 4;
return DD.getTargetData()->getPointerSize();
}
@@ -3495,12 +3497,14 @@
/// EmitValue - Emit label value.
///
void DIEObjectLabel::EmitValue(DwarfDebug &DD, unsigned Form) {
- DD.EmitReference(Label, false, Form == DW_FORM_data4);
+ bool IsSmall = Form == DW_FORM_data4;
+ DD.EmitReference(Label, false, IsSmall);
}
/// SizeOf - Determine size of label value in bytes.
///
unsigned DIEObjectLabel::SizeOf(const DwarfDebug &DD, unsigned Form) const {
+ if (Form == DW_FORM_data4) return 4;
return DD.getTargetData()->getPointerSize();
}
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42423 - in /llvm/trunk: include/llvm/CodeGen/RuntimeLibcalls.h include/llvm/Intrinsics.td lib/Analysis/ConstantFolding.cpp lib/CodeGen/SelectionDAG/LegalizeDAG.cpp lib/CodeG
On Sep 28, 2007, at 10:19 AM, Dale Johannesen wrote: > > On Sep 28, 2007, at 10:00 AM, Chris Lattner wrote: > >> Hi Dale, >>> >>>def int_powi_f32 : Intrinsic<[llvm_float_ty, llvm_float_ty, >>> llvm_i32_ty]>; >>>def int_powi_f64 : Intrinsic<[llvm_double_ty, llvm_double_ty, >>> llvm_i32_ty]>; >>> + def int_powi_f80 : Intrinsic<[llvm_f80_ty, llvm_f80_ty, >>> llvm_i32_ty]>; >>> + def int_powi_f128 : Intrinsic<[llvm_f128_ty, llvm_f128_ty, >>> llvm_i32_ty]>; >>> + def int_powi_ppcf128 : Intrinsic<[llvm_ppcf128_ty, >>> llvm_ppcf128_ty, >>> +llvm_i32_ty]>; >>> } >> >> Why not use anyfp? This would allow us to have one sqrt and one powi >> definition. > > Hard to explain; it just feels like the sort of thing where all the > values ought to be spelled out. Ok, then you're on the hook to expand docs/LangRef.html to enumerate all of these :) -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm-www/releases/index.html
Changes in directory llvm-www/releases: index.html updated: 1.39 -> 1.40 --- Log message: add 2.1 doc link and fix link to svn head dox --- Diffs of the changes: (+2 -1) index.html |3 ++- 1 files changed, 2 insertions(+), 1 deletion(-) Index: llvm-www/releases/index.html diff -u llvm-www/releases/index.html:1.39 llvm-www/releases/index.html:1.40 --- llvm-www/releases/index.html:1.39 Thu Sep 27 00:52:57 2007 +++ llvm-www/releases/index.htmlFri Sep 28 10:41:38 2007 @@ -75,7 +75,8 @@ source download and online: -http://llvm.org";>Current LLVM documentation +http://llvm.org/docs/";>Current LLVM SVN HEAD documentation +Documentation for LLVM 2.0 Documentation for LLVM 2.0 Documentation for LLVM 1.9 Documentation for LLVM 1.8 ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] GC patches again
BTW, thank you for splitting up this patch! It makes it much easier
to review.
> //===-- gc-3-collector.patch (+531) ---===//
>
> include/llvm/CodeGen/Collector.h (+134)
> lib/CodeGen/Collector.cpp (+359)
> lib/CodeGen/README.txt (+38)
>
> Collector is the base class for garbage collector code generators.
> This version enhances the previous patch to add root initialization
> as discussed here:
+#ifndef LLVM_CODEGEN_GC_H
+#define LLVM_CODEGEN_GC_H
Should probably be LLVM_CODEGEN_COLLECTOR_H
+
+#include "llvm/CodeGen/CollectorMetadata.h"
+#include
plz use instead of or neither if you don't need them.
+namespace llvm {
+
+ class AsmPrinter;
+ class FunctionPassManager;
+ class Pass;
+ class PassManager;
+ class TargetAsmInfo;
You can probably remove some of these.
In Collector.cpp, it looks like you have several redundant #include's.
Otherwise, looks great, plz commit.
> //===-- gc-4-integration.patch (+116 -17) -===//
>
> In this patch, Collector winds its tendrils throughout the compiler.
> Overhead should be minimal when disabled.
>
> I would particularly appreciate any feedback on this interface.
> The primary item of concern to me is that I exposed the desired
> collector to the compiler using a global. I have not decided on a
> better approach. In the meantime, it works and is simple.
I agree, this is not the right way to go. There are two problems:
1. introducing global data means that two instances of the codegen
can't be made at the same time. This is not acceptable. Fixing this
should be relatively straight forward: hang any mutable data off
MachineFunction or MachineModuleInfo as appropriate, and any
immutable target info off TargetMachine.
2. Adding a -gc option to llc isn't what we really want. Ideally,
the code generator would generate gc info for a function iff there is
a gcroot in it. This would allow the codegen to emit GC code code
that obviously uses it. Is there any case where the codegen has to
do something for a function with no gcroots (or declared safepoints
etc) in it?
-Chris
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42433 - in /llvm/trunk: lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86ISelLowering.h test/CodeGen/X86/memcpy.ll
> I think this behavior makes sense. If the size is variable, it could > be arbitrarily large. We should assume that memcpy (the library > implementation) is tuned as best as possible for handling the unknown > size case. Yes, we know that libc memcpy is better for big values and that inline is better for small values. When the value is not know at compile time, we can only guess. If we guess that it will be small, we get it wrong for any size bigger then an small arch specific limit (128 for x86-64 I think). If we guess that it will be large, we add it small overhead for small values, but a big saving for big ones. This might be a good case for profiling based optimization . > -Chris Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047 ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [patch] add gcroot attribute, test
>>> The llvm.gcroot intrinsic can be declared to take any types you >>> care to give it in the module, so long as its eventual type is >>> like void(**, *). >> >> Actually no, I need to update the langref.html document to make >> this explicit, thanks for reminding me. The issue is that if you >> link two modules with different 's, the two different >> intrinsics would have to be merged somehow. By forcing the >> intrinsic to a specific type this problem doesn't happen. > > I wondered about that. I'll have to fix several tests and the > Verifier. Are these the blessed prototypes? > > void @llvm.gcroot(i8**, i8*) > i8* @llvm.gcread(i8*, i8**) > void @llvm.gcwrite(i8*, i8*, i8**) Yep! -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42440 - /llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
Author: johannes Date: Fri Sep 28 13:44:17 2007 New Revision: 42440 URL: http://llvm.org/viewvc/llvm-project?rev=42440&view=rev Log: Fix long double -> uint64 conversion. Modified: llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp Modified: llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp?rev=42440&r1=42439&r2=42440&view=diff == --- llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (original) +++ llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp Fri Sep 28 13:44:17 2007 @@ -5398,8 +5398,12 @@ RTLIB::Libcall LC; if (Node->getOperand(0).getValueType() == MVT::f32) LC = RTLIB::FPTOUINT_F32_I64; -else +else if (Node->getOperand(0).getValueType() == MVT::f64) LC = RTLIB::FPTOUINT_F64_I64; +else if (Node->getOperand(0).getValueType() == MVT::f80 || + Node->getOperand(0).getValueType() == MVT::f128 || + Node->getOperand(0).getValueType() == MVT::ppcf128) + LC = RTLIB::FPTOUINT_LD_I64; Lo = ExpandLibCall(TLI.getLibcallName(LC), Node, false/*sign irrelevant*/, Hi); break; ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] lib/CodeGen/SelectionDAG/TargetLowering.cpp test/CodeGen/X86/2007-09-27-LDIntrinsics.ll utils/TableGen/CodeGenTarget.cpp utils/TableGen/IntrinsicEmitter.cpp
>> Why not use anyfp? This would allow us to have one sqrt and one powi >> definition. > > Hard to explain; it just feels like the sort of thing where all the > values ought to be spelled out. FWIW, sqrt was one of the main reasons we created anyfloat. The codegen portion of the vector-intrinsics patch depends on sqrt using anyfloat. Dan -- Dan Gohman, Cray Inc. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42441 - /llvm/trunk/CREDITS.TXT
Author: johannes Date: Fri Sep 28 13:46:28 2007 New Revision: 42441 URL: http://llvm.org/viewvc/llvm-project?rev=42441&view=rev Log: Record latest work. Modified: llvm/trunk/CREDITS.TXT Modified: llvm/trunk/CREDITS.TXT URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/CREDITS.TXT?rev=42441&r1=42440&r2=42441&view=diff == --- llvm/trunk/CREDITS.TXT (original) +++ llvm/trunk/CREDITS.TXT Fri Sep 28 13:46:28 2007 @@ -131,6 +131,8 @@ D: ARM constant islands improvements D: Tail merging improvements D: Rewrite X87 back end +D: Use APFloat for floating point constants widely throughout compiler +D: Implement X87 long double N: Eric Kidd W: http://randomhacks.net/ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42442 - in /llvm/trunk: include/llvm/CodeGen/ScheduleDAG.h lib/CodeGen/SelectionDAG/ScheduleDAG.cpp lib/CodeGen/SelectionDAG/ScheduleDAGList.cpp lib/CodeGen/SelectionDAG/Schedul
Author: evancheng
Date: Fri Sep 28 14:24:24 2007
New Revision: 42442
URL: http://llvm.org/viewvc/llvm-project?rev=42442&view=rev
Log:
Trim some unneeded fields.
Modified:
llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h
llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp
llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGList.cpp
llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
Modified: llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h?rev=42442&r1=42441&r2=42442&view=diff
==
--- llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h (original)
+++ llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h Fri Sep 28 14:24:24 2007
@@ -113,8 +113,6 @@
short NumSuccs; // # of sucss.
short NumPredsLeft; // # of preds not scheduled.
short NumSuccsLeft; // # of succs not scheduled.
-short NumChainPredsLeft;// # of chain preds not scheduled.
-short NumChainSuccsLeft;// # of chain succs not scheduled.
bool isTwoAddress : 1; // Is a two-address instruction.
bool isCommutable : 1; // Is a commutable instruction.
bool hasImplicitDefs : 1; // Has implicit physical reg defs.
@@ -131,7 +129,6 @@
SUnit(SDNode *node, unsigned nodenum)
: Node(node), InstanceNo(0), NodeNum(nodenum), Latency(0),
NumPreds(0), NumSuccs(0), NumPredsLeft(0), NumSuccsLeft(0),
-NumChainPredsLeft(0), NumChainSuccsLeft(0),
isTwoAddress(false), isCommutable(false), hasImplicitDefs(false),
isPending(false), isAvailable(false), isScheduled(false),
CycleBound(0), Cycle(0), Depth(0), Height(0),
@@ -147,19 +144,14 @@
return false;
Preds.push_back(SDep(N, PhyReg, Cost, isCtrl, isSpecial));
N->Succs.push_back(SDep(this, PhyReg, Cost, isCtrl, isSpecial));
- if (isCtrl) {
-if (!N->isScheduled)
- ++NumChainPredsLeft;
-if (!isScheduled)
- ++N->NumChainSuccsLeft;
- } else {
+ if (!isCtrl) {
++NumPreds;
++N->NumSuccs;
-if (!N->isScheduled)
- ++NumPredsLeft;
-if (!isScheduled)
- ++N->NumSuccsLeft;
}
+ if (!N->isScheduled)
+++NumPredsLeft;
+ if (!isScheduled)
+++N->NumSuccsLeft;
return true;
}
@@ -178,19 +170,14 @@
}
assert(FoundSucc && "Mismatching preds / succs lists!");
Preds.erase(I);
- if (isCtrl) {
-if (!N->isScheduled)
- --NumChainPredsLeft;
-if (!isScheduled)
- --NumChainSuccsLeft;
- } else {
+ if (!isCtrl) {
--NumPreds;
--N->NumSuccs;
-if (!N->isScheduled)
- --NumPredsLeft;
-if (!isScheduled)
- --N->NumSuccsLeft;
}
+ if (!N->isScheduled)
+--NumPredsLeft;
+ if (!isScheduled)
+--N->NumSuccsLeft;
return true;
}
return false;
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp?rev=42442&r1=42441&r2=42442&view=diff
==
--- llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp Fri Sep 28 14:24:24 2007
@@ -941,8 +941,6 @@
cerr << " # preds left : " << NumPredsLeft << "\n";
cerr << " # succs left : " << NumSuccsLeft << "\n";
- cerr << " # chain preds left : " << NumChainPredsLeft << "\n";
- cerr << " # chain succs left : " << NumChainSuccsLeft << "\n";
cerr << " Latency: " << Latency << "\n";
cerr << " Depth : " << Depth << "\n";
cerr << " Height : " << Height << "\n";
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGList.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGList.cpp?rev=42442&r1=42441&r2=42442&view=diff
==
--- llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGList.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGList.cpp Fri Sep 28 14:24:24
2007
@@ -116,15 +116,12 @@
/// ReleaseSucc - Decrement the NumPredsLeft count of a successor. Add it to
/// the PendingQueue if the count reaches zero.
void ScheduleDAGList::ReleaseSucc(SUnit *SuccSU, bool isChain) {
- if (!isChain)
-SuccSU->NumPredsLeft--;
- else
-SuccSU->NumChainPredsLeft--;
+ SuccSU->NumPredsLeft--;
- assert(SuccSU->NumPredsLeft >= 0 && SuccSU->NumChainPredsLeft >= 0 &&
+ assert(SuccSU->NumPredsLeft >= 0 &&
"List sc
Re: [llvm-commits] [llvm] r40115 - /llvm/trunk/docs/LangRef.html
On Jul 20, 2007, at 12:34 PM, Chandler Carruth wrote: > Author: chandlerc > Date: Fri Jul 20 14:34:37 2007 > New Revision: 40115 > > URL: http://llvm.org/viewvc/llvm-project?rev=40115&view=rev > Log: > This introduces the atomic operation intrinsics into the > documentation. This is > a preview for the intrinsics that are going to be implemented over > the next few > weeks. Chandler, what is the state of this work? This should be removed from LangRef unless it is going to be implemented "real soon now". -Chris > > Modified: > llvm/trunk/docs/LangRef.html > > Modified: llvm/trunk/docs/LangRef.html > URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ > LangRef.html?rev=40115&r1=40114&r2=40115&view=diff > > == > > --- llvm/trunk/docs/LangRef.html (original) > +++ llvm/trunk/docs/LangRef.html Fri Jul 20 14:34:37 2007 > @@ -191,6 +191,15 @@ > >Debugger intrinsics >Exception Handling intrinsics > + Atomic Operations and > Synchronization Intrinsics > + > + 'llvm.atomic.lcs.*' > Intrinsic > + 'llvm.atomic.ls.*' > Intrinsic > + 'llvm.atomic.las.*' > Intrinsic > + 'llvm.atomic.lss.*' > Intrinsic > + href="#int_memory_barrier">'llvm.memory.barrier' > Intrinsic > + > + >General intrinsics > > href="#int_var_annotation">'llvm.var.annotation' > @@ -4822,6 +4831,302 @@ > > > > + Atomic Operations and Synchronization > Intrinsics > + > + > + > + > + These intrinsic functions expand the "universal IR" of LLVM to > represent > + hardware constructs for atomic operations and memory > synchronization. This > + provides an interface to the hardware, not an interface to the > programmer. It > + is aimed at a low enough level to allow any programming models > or APIs which > + need atomic behaviors to map cleanly onto it. It is also modeled > primarily on > + hardware behavior. Just as hardware provides a "unviresal IR" > for source > + languages, it also provides a starting point for developing a > "universal" > + atomic operation and synchronization IR. > + > + > + These do not form an API such as high-level threading > libraries, > + software transaction memory systems, atomic primitives, and > intrinsic > + functionss as found in BSD, GNU libc, atomic_ops, APR, and other > system and > + application libraries. The hardware interface provided by LLVM > should allow > + a clean implementation of all of these APIs and parallel > programming models. > + No one model or paradigm should be selected above others unless > the hardware > + itself ubiquitously does so. > + > + > + > + > + > + 'llvm.atomic.lcs.*' Intrinsic > + > + > +Syntax: > + > + This is an overloaded intrinsic. You can use > llvm.atomic.lcs on any > + integer bit width. Not all targets support all bit widths however. > + > +declare i8 @llvm.atomic.lcs.i8.i8p.i8.i8( i8*, i8 > , i8 ) > +declare i16 @llvm.atomic.lcs.i16.i16p.i16.i16( i16* , > i16 , i16 ) > +declare i32 @llvm.atomic.lcs.i32.i32p.i32.i32( i32* , > i32 , i32 ) > +declare i64 @llvm.atomic.lcs.i64.i64p.i64.i64( i64* , > i64 , i64 ) > + > + > +Overview: > + > + This loads a value in shared memory and compares it to a given > value. If they > + are equal, it stores a new value into the shared memory. > + > +Arguments: > + > + The llvm.atomic.lcs intrinsic takes three arguments. > The result as > + well as both cmp and val must be integer > values with the > + same bit width. The ptr argument must be a pointer to a > value of > + this integer type. While any bit width integer may be used, > targets may only > + lower representations they support in hardware. > + > +Semantics: > + > + This entire intrinsic must be executed atomically. It first > loads the value > + in shared memory pointed to by ptr and compares it with > the value > + cmp. If they are equal, val is stored into the > shared > + memory. The loaded value is yielded in all cases. This provides the > + equivalent of an atomic compare-and-swap operation within the > SSA framework. > + > +Examples: > + > +%ptr = malloc i32 > +store i32 4, %ptr > + > +%val1 = add i32 4, 4 > +%result1 = call i32 @llvm.atomic.lcs( i32* %ptr, i32 4, %val1 ) > + ; yields > {i32}:result1 = 4 > +%stored1 = icmp eq i32 %result1, 4 ; yields {i1}:stored1 > = true > +%memval1 = load i32* %ptr; yields > {i32}:memval1 = 8 > + > +%val2 = add i32 1, 1 > +%result2 = call i32 @llvm.atomic.lcs( i32* %ptr, i32 5, %val2 ) > + ; yields > {i32}:result2 = 8 > +%stored2 = icmp eq i32 %result2, 5 ; yields {i1}:stored2 > = false > +%memval2 = load i32
Re: [llvm-commits] Trampoline changes
On Sep 17, 2007, at 3:45 AM, Duncan Sands wrote:
>>> My hope was that some of these trampoline calls could be eliminated
>>> using this optimization. But for...
>>
>> It would be pretty straight-forward to implement an IPO pass that
>> turns trampoline pointers into fat pointers in cases like this.
>
> that's a very interesting idea. It sounds hard to an LLVM minnow like
> myself though :)
>
>> It sounds like it could be a big win for the container library,
>> because
>> the container (if the routines get marked internal) would
>> automatically be converted to take fat pointers, even if there are
>> multiple different trampolines being passed in.
>
> Yes, it would be pretty nice. But how feasible is it? Surely it will
> only work well if we can find out all or at least most of the
> places that
> the trampoline function pointer gets passed to.
It is very feasible and would be pretty straight-forward. Consider
this code in C:
static void foo(funcptr_t P) {
P();
}
void a() {
tmp = maketrampoline(somefunc1, somedata);
foo(tmp);
}
void b() {
tmp = maketrampoline(somefunc2, somedata);
foo(tmp);
}
void c() {
tmp = maketrampoline(somefunc3, somedata);
foo(tmp);
}
The idea is to transform it into:
static void foo(funcptr2_t P1, void *Data) {
P1(Data);
}
void a() {
tmp = maketrampoline(somefunc1, somedata); // probably dead now.
foo(somefunc1, somedata);
}
void b() {
tmp = maketrampoline(somefunc2, somedata); // probably dead now.
foo(somefunc2, somedata);
}
void c() {
tmp = maketrampoline(somefunc3, somedata); // probably dead now
foo(somefunc3, somedata);
}
The checks involved would be:
1. The function (foo) has to have internal linkage.
2. The function is only called by direct calls, no taking the address
of foo etc.
3. It takes some function pointer as an argument.
4. all call sites (which you know are direct) pass in a function
pointer obtained from llvm.trampoline
In this case, you can handle it, transforming it as above. The nice
thing about this is that the xform doesn't increase code size, so
it's always a win, regardless of how large foo is.
If you wanted to do this, this should go into the arg promotion pass,
which already does much of this analysis.
-Chris
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] lib/CodeGen/SelectionDAG/TargetLowering.cpp test/CodeGen/X86/2007-09-27-LDIntrinsics.ll utils/TableGen/CodeGenTarget.cpp utils/TableGen/IntrinsicEmitter.cpp
On Sep 28, 2007, at 11:58 AM, Dan Gohman wrote: >>> Why not use anyfp? This would allow us to have one sqrt and one >>> powi >>> definition. >> >> Hard to explain; it just feels like the sort of thing where all the >> values ought to be spelled out. > > FWIW, sqrt was one of the main reasons we created anyfloat. The > codegen portion of the vector-intrinsics patch depends on sqrt > using anyfloat. ? It wasn't before my change, either. > Dan > > -- > Dan Gohman, Cray Inc. > ___ > llvm-commits mailing list > llvm-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r40628 - in /llvm/trunk: lib/Target/X86/X86InstrFPStack.td lib/Target/X86/X86InstrFormats.td lib/Target/X86/X86InstrInfo.td lib/Target/X86/X86InstrMMX.td lib/Target/X86/X86In
Evan, ping? -Chris On Aug 1, 2007, at 5:47 PM, Chris Lattner wrote: > On Jul 31, 2007, at 1:04 AM, Evan Cheng wrote: >> Author: evancheng >> Date: Tue Jul 31 03:04:03 2007 >> New Revision: 40628 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=40628&view=rev >> Log: >> Redo and generalize previously removed opt for pinsrw: (vextract >> (v4i32 bc (v4f32 s2v (f32 load ))), 0) -> (i32 load ) > > >> + >> +// (vextract (v4i32 bc (v4f32 s2v (f32 load $addr))), 0) -> (i32 >> load $addr) >> +def : Pat<(vector_extract >> + (bc_v4i32 (v4f32 (scalar_to_vector (loadf32 addr: >> $src, (iPTR 0)), >> + (MOV32rm addr:$src)>; >> +def : Pat<(vector_extract >> + (bc_v2i64 (v2f64 (scalar_to_vector (loadf64 addr: >> $src, (iPTR 0)), >> + (MOV64rm addr:$src)>; > > Would it be possible (and would it make sense) to do this in the dag > combiner rather than as a target-specific pattern? > > -Chris > ___ > llvm-commits mailing list > llvm-commits@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] lib/CodeGen/SelectionDAG/TargetLowering.cpp test/CodeGen/X86/2007-09-27-LDIntrinsics.ll utils/TableGen/CodeGenTarget.cpp utils/TableGen/IntrinsicEmitter.cpp
>> FWIW, sqrt was one of the main reasons we created anyfloat. The >> codegen portion of the vector-intrinsics patch depends on sqrt >> using anyfloat. > > ? It wasn't before my change, either. The codegen portion of that patch isn't committed yet. But if there's any reason why anyfloat isn't suitable for the likes of sqrt, I'd like to know of it before I get around to updating and submitting the patch :-). Dan -- Dan Gohman, Cray Inc. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42443 - /llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
Author: evancheng
Date: Fri Sep 28 14:37:35 2007
New Revision: 42443
URL: http://llvm.org/viewvc/llvm-project?rev=42443&view=rev
Log:
Remove a poor scheduling heuristic.
Modified:
llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp?rev=42443&r1=42442&r2=42443&view=diff
==
--- llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp Fri Sep 28
14:37:35 2007
@@ -1071,26 +1071,6 @@
return MaxCycle;
}
-/// calcMaxScratches - Returns an cost estimate of the worse case requirement
-/// for scratch registers. Live-in operands and live-out results don't count
-/// since they are "fixed".
-static unsigned calcMaxScratches(const SUnit *SU) {
- unsigned Scratches = 0;
- for (SUnit::const_pred_iterator I = SU->Preds.begin(), E = SU->Preds.end();
- I != E; ++I) {
-if (I->isCtrl) continue; // ignore chain preds
-if (!I->Dep->Node || I->Dep->Node->getOpcode() != ISD::CopyFromReg)
- Scratches++;
- }
- for (SUnit::const_succ_iterator I = SU->Succs.begin(), E = SU->Succs.end();
- I != E; ++I) {
-if (I->isCtrl) continue; // ignore chain succs
-if (!I->Dep->Node || I->Dep->Node->getOpcode() != ISD::CopyToReg)
- Scratches += 10;
- }
- return Scratches;
-}
-
// Bottom up
bool bu_ls_rr_sort::operator()(const SUnit *left, const SUnit *right) const {
// There used to be a special tie breaker here that looked for
@@ -1133,23 +1113,14 @@
if (LDist < RDist)
return true;
else if (LDist == RDist) {
- // Intuitively, it's good to push down instructions whose results are
- // liveout so their long live ranges won't conflict with other values
- // which are needed inside the BB. Further prioritize liveout
instructions
- // by the number of operands which are calculated within the BB.
- unsigned LScratch = calcMaxScratches(left);
- unsigned RScratch = calcMaxScratches(right);
- if (LScratch > RScratch)
+ if (left->Height > right->Height)
return true;
- else if (LScratch == RScratch)
-if (left->Height > right->Height)
+ else if (left->Height == right->Height)
+if (left->Depth < right->Depth)
return true;
-else if (left->Height == right->Height)
- if (left->Depth < right->Depth)
+else if (left->Depth == right->Depth)
+ if (left->CycleBound > right->CycleBound)
return true;
- else if (left->Depth == right->Depth)
-if (left->CycleBound > right->CycleBound)
- return true;
}
}
return false;
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] lib/CodeGen/SelectionDAG/TargetLowering.cpp test/CodeGen/X86/2007-09-27-LDIntrinsics.ll utils/TableGen/CodeGenTarget.cpp utils/TableGen/IntrinsicEmitter.cpp
On Sep 28, 2007, at 12:35 PM, Dan Gohman wrote: >>> FWIW, sqrt was one of the main reasons we created anyfloat. The >>> codegen portion of the vector-intrinsics patch depends on sqrt >>> using anyfloat. >> >> ? It wasn't before my change, either. > > The codegen portion of that patch isn't committed yet. But if > there's any > reason why anyfloat isn't suitable for the likes of sqrt, I'd like > to know > of it before I get around to updating and submitting the patch :-). > > Dan I see. OK, that sounds like a better reason to use anyfloat than my reason not to:) I'll look into changing it. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42444 - /llvm/trunk/lib/VMCore/Value.cpp
Author: lattner
Date: Fri Sep 28 15:09:40 2007
New Revision: 42444
URL: http://llvm.org/viewvc/llvm-project?rev=42444&view=rev
Log:
Make Value::getNameLen not crash on an empty name, fixing PR1712.
Modified:
llvm/trunk/lib/VMCore/Value.cpp
Modified: llvm/trunk/lib/VMCore/Value.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/Value.cpp?rev=42444&r1=42443&r2=42444&view=diff
==
--- llvm/trunk/lib/VMCore/Value.cpp (original)
+++ llvm/trunk/lib/VMCore/Value.cpp Fri Sep 28 15:09:40 2007
@@ -128,7 +128,7 @@
/// getNameLen - Return the length of the string, correctly handling nul
/// characters embedded into them.
unsigned Value::getNameLen() const {
- return Name->getKeyLength();
+ return Name ? Name->getKeyLength() : 0;
}
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Trampoline changes
Hi Chris,
> >>> My hope was that some of these trampoline calls could be eliminated
> >>> using this optimization. But for...
> >>
> >> It would be pretty straight-forward to implement an IPO pass that
> >> turns trampoline pointers into fat pointers in cases like this.
> >
> > that's a very interesting idea. It sounds hard to an LLVM minnow like
> > myself though :)
> >
> >> It sounds like it could be a big win for the container library,
> >> because
> >> the container (if the routines get marked internal) would
> >> automatically be converted to take fat pointers, even if there are
> >> multiple different trampolines being passed in.
> >
> > Yes, it would be pretty nice. But how feasible is it? Surely it will
> > only work well if we can find out all or at least most of the
> > places that
> > the trampoline function pointer gets passed to.
>
> It is very feasible and would be pretty straight-forward. Consider
> this code in C:
>
> static void foo(funcptr_t P) {
>P();
> }
>
> void a() {
>tmp = maketrampoline(somefunc1, somedata);
>foo(tmp);
> }
> void b() {
>tmp = maketrampoline(somefunc2, somedata);
>foo(tmp);
> }
> void c() {
>tmp = maketrampoline(somefunc3, somedata);
>foo(tmp);
> }
this would probably suffice for a decent percentage of cases. However things
get more complicated once you have multiple trampolines (because of multiple
nested functions) and multiply nested functions (functions nested inside other
nested functions). The multiple trampoline problem is kind of dumb: the first
thing that is done to the result of the init_trampoline call is that it is
stored
in a local variable. Since init_trampoline is IntrWriteMem (because it stashes
somefunc and somedata in the trampoline) if there are two init_trampoline calls
in a row then, when the result of the first one is read from memory in order to
be used, LLVM won't recognise it as the result of an init_trampoline call
anymore,
because it thinks it might have been clobbered by the other call (IntrWriteMem
causes LLVM to be very pessimistic). The other problem (nested functions nested
within other nested functions) is that gcc passes the trampoline pointer to
child functions in a struct (the frame struct). So if you want to handle this
case then you have to track where this struct is being passed to and do more
complicated analysis.
> The idea is to transform it into:
>
> static void foo(funcptr2_t P1, void *Data) {
>P1(Data);
> }
>
> void a() {
>tmp = maketrampoline(somefunc1, somedata); // probably dead now.
>foo(somefunc1, somedata);
> }
> void b() {
>tmp = maketrampoline(somefunc2, somedata); // probably dead now.
>foo(somefunc2, somedata);
> }
> void c() {
>tmp = maketrampoline(somefunc3, somedata); // probably dead now
>foo(somefunc3, somedata);
> }
>
> The checks involved would be:
>
> 1. The function (foo) has to have internal linkage.
Right.
> 2. The function is only called by direct calls, no taking the address
> of foo etc.
Yup.
> 3. It takes some function pointer as an argument.
Yes, it becomes much harder if the function pointer is passed in in
another way, for example in a struct.
> 4. all call sites (which you know are direct) pass in a function
> pointer obtained from llvm.trampoline
And the functions the trampolines were made from have their "nest"
parameter at the same position (this is the case for code coming
from gcc, where it is always the first parameter).
Also
5. Within foo, you need to check that nothing too complicated is
done to P1, for example it isn't stored in a global or passed to
some other function.
> In this case, you can handle it, transforming it as above. The nice
> thing about this is that the xform doesn't increase code size, so
> it's always a win, regardless of how large foo is.
Well, you do have to push another parameter when calling foo, and
when foo calls P1 :)
> If you wanted to do this, this should go into the arg promotion pass,
> which already does much of this analysis.
It's a very nice idea - I'm not sure how many cases it would capture
though.
Best wishes,
Duncan.
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42367 - in /llvm/trunk: Xcode/LLVM.xcodeproj/project.pbxproj bindings/ocaml/Makefile.ocaml bindings/ocaml/bitwriter/Makefile bindings/ocaml/llvm/llvm.ml bindings/ocaml/llvm/
> URL: http://llvm.org/viewvc/llvm-project?rev=42367&view=rev > Log: > Added C and Ocaml bindings for functions, basic blocks, and > instruction creation. No support yet for instruction introspection. > > Also eliminated allocas from the Ocaml bindings for portability, > and avoided unnecessary casts. > > == > > --- llvm/trunk/include/llvm/CHelpers.h (original) > +++ llvm/trunk/include/llvm/CHelpers.h Wed Sep 26 15:56:12 2007 Hi Gordon, I think it makes sense for CHelpers.h to move into include/llvm/ Support instead of include/llvm. What do you think? -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] Size of long double (X86_FP80Ty)
Hi Dale, on my machine (x86-32, linux) LLVM considers long double to
have a size of 10 bytes and an alignment of 4 bytes. GCC gives it a
size of 12 bytes and an alignment of 4 bytes (of course only the first
80 bits (10 bytes) are actually used - the rest is padding).
I can see several problems with a 10 byte size.
First, problems that aren't related to gcc. In an array of long double,
the elements may not be aligned even if the array is aligned. This is
because the usual invariant "the size is a multiple of the alignment" does
not hold for size 10, alignment 4. I'm betting that the logic for working
out alignments of loads and stores in LLVM is not expecting this! Since
this type only exists on x86, which is pretty lenient about unaligned
pointer access, I suppose this might not really matter. Isn't unaligned
access slower than aligned access though? Anyway, it seems to me much
better to avoid this can of worms and have the size be a multiple of the
alignment.
Second, problems related to gcc. We convert long double to X86_FP80Ty
(which I've been referring to as long double). The result is that the size
of the gcc type is not equal to the size of the LLVM type. This causes all
kinds of problems with arrays and pointer arithmetic. That's the reason
for the check that sizes are the same (which you turned off in this case,
tut tut!). For example, suppose you declare an array of long doubles,
cast to an i8* and start moving around in it based on sizeof(long double).
Well you'll end up at the wrong place because sizeof is the gcc size (12)
but LLVM will have placed the elements 10 bytes apart! This also has
knock-on effects, like LLVM arrays of long doubles having different
lengths to the corresponding gcc arrays etc. If you think about it I
hope you will agree that it is important to convert gcc types to LLVM
types of the same size.
By the way, are there any standards that require size to be a multiple
of alignment?
The solution I would prefer is: make getTypeSize return 12 for long double,
have getTypeSizeInBits return 80 (I think this should be renamed to
getBitsUsedByType or something like that, see APInt comments below). Make
it a requirement that getTypeSize always returns a multiple of the alignment.
Document that getTypeSize is the offset between successive elements in arrays
of this type, or between fields in a struct; and that loads and stores of this
type can write up to this many bytes. Document that getBitsUsedByType returns
the minimum number of bits needed to hold all values of this type, and that
this can be less than 8*getTypeSize. Correct all places that assume that
getBitsUsedByType is 8*getTypeSize (like the check that the gcc type has
the same size as the llvm type, which should be using 8*getTypeSize).
Note that this is exactly how it is already for APInt. Consider a type
like i36. For this, getTypeSize returns 8, i.e. 64 bits, while
getTypeSizeInBits returns 36. Thus getTypeSize corresponds to gcc's
TYPE_SIZE while getTypeSizeInBits corresponds to TYPE_PRECISION. This
seems like a good model to me.
That said, other solutions are possible. For example, we could ignore
the unaligned array element problem, and alter gcc so that TYPE_SIZE
for long double becomes 80 bits. I have no idea what kind of problems
this might cause, if any.
Or we could convert long double to a struct { X86_FP80Ty, i16 }, and
fix up all the floating point stuff in llvm-convert. Chris mentioned
to me on IRC that this is a pessimisation in general, and would rather
have X86_FP80Ty be used for scalar operations (so you can continue to
use registers) but have { X86_FP80Ty, i16 } be used for loads and stores
to memory. He also noted that this kind of thing would be also helpful
for Darwin's funky 32 bit boolean type (which would be more optimally
manipulated as in i1 in scalar expressions, but needs to be stored as
32 bits). Thus he suggested associating two LLVM types with each primitive
gcc type: a type used for lvalues (i.e. memory access) and a type used for
scalar operations (LLVM register operations). The lvalue type would always
have the same size as the gcc type, while the scalar type could differ in size.
What do you think?
Best wishes,
Duncan.
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42270 - in /llvm/trunk: lib/Transforms/Scalar/LICM.cpp test/Transforms/LICM/2007-09-24-PromoteNullValue.ll
On Sep 24, 2007, at 1:02 PM, Devang Patel wrote:
> Author: dpatel
> Date: Mon Sep 24 15:02:42 2007
> New Revision: 42270
>
> URL: http://llvm.org/viewvc/llvm-project?rev=42270&view=rev
> Log:
> Do not promote null values because it may be unsafe to do so.
Hi Devang,
Unfortunately, this approach is not the right way to go.
In the testcase you checked in, the fact that the store is to a null
point is not the problem. For example, you could change the testcase
to store through a pointer argument, where a callee could pass in a
null or other invalid pointer.
The issue is that the loop basically looks like this:
void foo() {
for () {
if (Cond) {
*P += 1;
}
}
}
And ends up being transformed into:
void foo() {
tmp = *P
for () {
if (Cond) {
tmp += 1;
}
}
*P = tmp;
}
In the former code, *P is only accessed if Cond is true, in the later
case it is unconditionally accessed. In your testcase, P is null,
but that need not be the case: it could be any arbitrarily bad pointer.
Basically, it is only safe to do the memory promotion if the loop is
guaranteed to access the memory location. In this loop:
void foo() {
for () {
print(*P);
if (Cond) {
*P = 1;
}
}
}
it is safe to promote *P, because it has an unconditional use in the
loop header.
Can you please continue hacking on this, solving the problem in its
full generality?
-Chris
> Added:
> llvm/trunk/test/Transforms/LICM/2007-09-24-PromoteNullValue.ll
> Modified:
> llvm/trunk/lib/Transforms/Scalar/LICM.cpp
>
> Modified: llvm/trunk/lib/Transforms/Scalar/LICM.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/
> Scalar/LICM.cpp?rev=42270&r1=42269&r2=42270&view=diff
>
> ==
>
> --- llvm/trunk/lib/Transforms/Scalar/LICM.cpp (original)
> +++ llvm/trunk/lib/Transforms/Scalar/LICM.cpp Mon Sep 24 15:02:42 2007
> @@ -800,6 +800,10 @@
>break;
> }
>
> + // Do not promote null values because it may be unsafe to do
> so.
> + if (isa(V))
> +PointerOk = false;
> +
>if (GetElementPtrInst *GEP = dyn_cast(V)) {
> // If GEP base is NULL then the calculated address used by
> Store or
> // Load instruction is invalid. Do not promote this value
> because
>
> Added: llvm/trunk/test/Transforms/LICM/2007-09-24-PromoteNullValue.ll
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/Transforms/
> LICM/2007-09-24-PromoteNullValue.ll?rev=42270&view=auto
>
> ==
>
> --- llvm/trunk/test/Transforms/LICM/2007-09-24-PromoteNullValue.ll
> (added)
> +++ llvm/trunk/test/Transforms/LICM/2007-09-24-PromoteNullValue.ll
> Mon Sep 24 15:02:42 2007
> @@ -0,0 +1,46 @@
> +; Do not promote null value because it may be unsafe to do so.
> +; RUN: llvm-as < %s | opt -licm | llvm-dis | not grep promoted
> +
> +define i32 @f(i32 %foo, i32 %bar, i32 %com) {
> +entry:
> + %tmp2 = icmp eq i32 %foo, 0 ; [#uses=1]
> + br i1 %tmp2, label %cond_next, label %cond_true
> +
> +cond_true: ; preds = %entry
> + br label %return
> +
> +cond_next: ; preds = %entry
> + br label %bb
> +
> +bb: ; preds = %bb15, %cond_next
> + switch i32 %bar, label %bb15 [
> + i32 1, label %bb6
> + ]
> +
> +bb6: ; preds = %bb
> + %tmp8 = icmp eq i32 %com, 0 ; [#uses=1]
> + br i1 %tmp8, label %cond_next14, label %cond_true11
> +
> +cond_true11: ; preds = %bb6
> + br label %return
> +
> +cond_next14: ; preds = %bb6
> + store i8 0, i8* null
> + br label %bb15
> +
> +bb15:; preds = %cond_next14, %bb
> + br label %bb
> +
> +return: ; preds = %cond_true11, %cond_true
> + %storemerge = phi i32 [ 0, %cond_true ], [ undef, %
> cond_true11 ] ; [#uses=1]
> + ret i32 %storemerge
> +}
> +
> +define i32 @kdMain() {
> +entry:
> + %tmp1 = call i32 @f( i32 0, i32 1, i32 1 ) ;
> [#uses=0]
> + call void @exit( i32 0 )
> + unreachable
> +}
> +
> +declare void @exit(i32)
>
>
> ___
> llvm-commits mailing list
> llvm-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42448 - /llvm/trunk/lib/System/DynamicLibrary.cpp
Author: lattner Date: Fri Sep 28 15:50:50 2007 New Revision: 42448 URL: http://llvm.org/viewvc/llvm-project?rev=42448&view=rev Log: really fix PR1581, thanks to Daniel Dunbar for pointing this out. Modified: llvm/trunk/lib/System/DynamicLibrary.cpp Modified: llvm/trunk/lib/System/DynamicLibrary.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/System/DynamicLibrary.cpp?rev=42448&r1=42447&r2=42448&view=diff == --- llvm/trunk/lib/System/DynamicLibrary.cpp (original) +++ llvm/trunk/lib/System/DynamicLibrary.cpp Fri Sep 28 15:50:50 2007 @@ -62,7 +62,7 @@ lt_dlhandle a_handle = lt_dlopen(0); - assert(a_handle == 0 && "Can't open program as dynamic library"); + assert(a_handle && "Can't open program as dynamic library"); handle = a_handle; OpenedHandles.push_back(a_handle); ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Size of long double (X86_FP80Ty)
I tried having the padding by part of the type but concluded this way is
better (although there's a bug, see below.)
The idea is that the size represents how many bytes actually have data,
and the padding in structs and arrays is handled by the alignment (btw,
size and alignment are both 16 on Darwin, rather than 12/4.)
Exercising
this a bit, there's a bug in array referencing, but this seems to
work for structs
and array allocations. The end data layout is definitely supposed to
be the
same as gcc's; ABI compatibility is a requirement, at least for us.
sizeof is computed by the FE, of course, so things like
(char*)&ld + i*sizeof(long double)
work fine.
I'm not persuaded the approach is wrong; if we
make the padding part of the type it has to have a deterministic
value, or
bitwise comparisons don't work, and there's all those useless bytes
being
carried around. (If you experiment with gcc, you'll find those bytes
are not
deterministic; when copying long doubles, sometimes it uses fldt/fstpt
to get just 10 bytes, other times it will get 12 or 16, which may be
uninitialized. I want to avoid this sort of thing.)
I need to fix the array-reference issue; the code that translates
getelementpr
to bytes needs to look at alignment(element type). Do you have any
other
examples that don't work?
On Sep 28, 2007, at 1:04 PM, Duncan Sands wrote:
> Hi Dale, on my machine (x86-32, linux) LLVM considers long double to
> have a size of 10 bytes and an alignment of 4 bytes. GCC gives it a
> size of 12 bytes and an alignment of 4 bytes (of course only the first
> 80 bits (10 bytes) are actually used - the rest is padding).
>
> I can see several problems with a 10 byte size.
>
> First, problems that aren't related to gcc. In an array of long
> double,
> the elements may not be aligned even if the array is aligned. This is
> because the usual invariant "the size is a multiple of the
> alignment" does
> not hold for size 10, alignment 4. I'm betting that the logic for
> working
> out alignments of loads and stores in LLVM is not expecting this!
> Since
> this type only exists on x86, which is pretty lenient about unaligned
> pointer access, I suppose this might not really matter. Isn't
> unaligned
> access slower than aligned access though? Anyway, it seems to me much
> better to avoid this can of worms and have the size be a multiple
> of the
> alignment.
>
> Second, problems related to gcc. We convert long double to X86_FP80Ty
> (which I've been referring to as long double). The result is that
> the size
> of the gcc type is not equal to the size of the LLVM type. This
> causes all
> kinds of problems with arrays and pointer arithmetic. That's the
> reason
> for the check that sizes are the same (which you turned off in this
> case,
> tut tut!). For example, suppose you declare an array of long doubles,
> cast to an i8* and start moving around in it based on sizeof(long
> double).
> Well you'll end up at the wrong place because sizeof is the gcc
> size (12)
> but LLVM will have placed the elements 10 bytes apart! This also has
> knock-on effects, like LLVM arrays of long doubles having different
> lengths to the corresponding gcc arrays etc. If you think about it I
> hope you will agree that it is important to convert gcc types to LLVM
> types of the same size.
>
> By the way, are there any standards that require size to be a multiple
> of alignment?
>
> The solution I would prefer is: make getTypeSize return 12 for long
> double,
> have getTypeSizeInBits return 80 (I think this should be renamed to
> getBitsUsedByType or something like that, see APInt comments
> below). Make
> it a requirement that getTypeSize always returns a multiple of the
> alignment.
> Document that getTypeSize is the offset between successive elements
> in arrays
> of this type, or between fields in a struct; and that loads and
> stores of this
> type can write up to this many bytes. Document that
> getBitsUsedByType returns
> the minimum number of bits needed to hold all values of this type,
> and that
> this can be less than 8*getTypeSize. Correct all places that
> assume that
> getBitsUsedByType is 8*getTypeSize (like the check that the gcc
> type has
> the same size as the llvm type, which should be using 8*getTypeSize).
>
> Note that this is exactly how it is already for APInt. Consider a
> type
> like i36. For this, getTypeSize returns 8, i.e. 64 bits, while
> getTypeSizeInBits returns 36. Thus getTypeSize corresponds to gcc's
> TYPE_SIZE while getTypeSizeInBits corresponds to TYPE_PRECISION. This
> seems like a good model to me.
>
> That said, other solutions are possible. For example, we could ignore
> the unaligned array element problem, and alter gcc so that TYPE_SIZE
> for long double becomes 80 bits. I have no idea what kind of problems
> this might cause, if any.
>
> Or we could convert long double to a struct { X86_FP80Ty, i16 }, and
> fix up all
Re: [llvm-commits] Trampoline changes
>> It is very feasible and would be pretty straight-forward. Consider
>> this code in C:
>>
>> static void foo(funcptr_t P) {
>>P();
>> }
>>
>> void a() {
>>tmp = maketrampoline(somefunc1, somedata);
>>foo(tmp);
>> }
>> void b() {
>>tmp = maketrampoline(somefunc2, somedata);
>>foo(tmp);
>> }
>> void c() {
>>tmp = maketrampoline(somefunc3, somedata);
>>foo(tmp);
>> }
>
> this would probably suffice for a decent percentage of cases.
> However things
> get more complicated once you have multiple trampolines (because of
> multiple
> nested functions) and multiply nested functions (functions nested
> inside other
> nested functions).
If you're interested in this, you should start simple and generalize
out form there. Handling multiply nested functions and other harder
cases can build on the basic case when it's implemented and you get
experience with it.
> The multiple trampoline problem is kind of dumb: the first
> thing that is done to the result of the init_trampoline call is
> that it is stored
> in a local variable. Since init_trampoline is IntrWriteMem
> (because it stashes
> somefunc and somedata in the trampoline) if there are two
> init_trampoline calls
> in a row then, when the result of the first one is read from memory
> in order to
> be used, LLVM won't recognise it as the result of an
> init_trampoline call anymore,
> because it thinks it might have been clobbered by the other call
> (IntrWriteMem
> causes LLVM to be very pessimistic). The other problem (nested
> functions nested
> within other nested functions) is that gcc passes the trampoline
> pointer to
> child functions in a struct (the frame struct). So if you want to
> handle this
> case then you have to track where this struct is being passed to
> and do more
> complicated analysis.
Sure, but you want to optimize trampolines better in any case :)
>> 3. It takes some function pointer as an argument.
>
> Yes, it becomes much harder if the function pointer is passed in in
> another way, for example in a struct.
Yep, but fortunately other optimizations already hack on these in
some cases. You're not going to be able to do the fully general
case efficiently. It's probably not worth worrying about until the
basic case works.
>> 4. all call sites (which you know are direct) pass in a function
>> pointer obtained from llvm.trampoline
>
> And the functions the trampolines were made from have their "nest"
> parameter at the same position (this is the case for code coming
> from gcc, where it is always the first parameter).
I don't know what this means, but I believe you :)
> Also
> 5. Within foo, you need to check that nothing too complicated is
> done to P1, for example it isn't stored in a global or passed to
> some other function.
Actually, worse case, you could just make a trampoline in foo.
However, you're right that this is only worth doing if there are
calls to the fn pointer in foo. OTOH, propagating the trampoline
creation site down to foo will allow it to be further propagated into
functions that foo might call.
>> In this case, you can handle it, transforming it as above. The nice
>> thing about this is that the xform doesn't increase code size, so
>> it's always a win, regardless of how large foo is.
>
> Well, you do have to push another parameter when calling foo, and
> when foo calls P1 :)
Yes, but you'll usually get to nuke the trampoline, saving space :)
>> If you wanted to do this, this should go into the arg promotion pass,
>> which already does much of this analysis.
>
> It's a very nice idea - I'm not sure how many cases it would capture
> though.
Me neither! I'd suggest building some ada code, running llvm-ld on
it to internalize it, then looking for calls to trampoline creation
and seeing how they are used.
-Chris
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42285 - in /llvm/trunk/lib/Target/X86: X86FloatingPoint.cpp X86ISelLowering.cpp X86ISelLowering.h X86InstrFPStack.td X86InstrInfo.cpp X86InstrInfo.td X86InstrSSE.td X86Instr
> URL: http://llvm.org/viewvc/llvm-project?rev=42285&view=rev > Log: > Added support for new condition code modeling scheme (i.e. physical > register dependency). These are a bunch of instructions that are > duplicated so the x86 backend can support both the old and new > schemes at the same time. They will be deleted after > all the kinks are worked out. Nifty! > == > > --- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original) > +++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Mon Sep 24 > 20:57:46 2007 > @@ -31,6 +31,7 @@ > #include "llvm/CodeGen/MachineInstrBuilder.h" > #include "llvm/CodeGen/SelectionDAG.h" > #include "llvm/CodeGen/SSARegMap.h" > +#include "llvm/Support/CommandLine.h" This #include is dead. It would be nice to remove the duplicate instructions at some point, but they are fine as an intermediate step. -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Size of long double (X86_FP80Ty)
Hi Dale, > I tried having the padding by part of the type but concluded this way is > better (although there's a bug, see below.) > > The idea is that the size represents how many bytes actually have data, > and the padding in structs and arrays is handled by the alignment (btw, > size and alignment are both 16 on Darwin, rather than 12/4.) I think then TargetData should have a new method for obtaining the number of bytes between successive array elements or struct fields of that type. This is what would correspond to gcc's TYPE_SIZE. Then ConvertType can check that this value for the llvm type is equal to the gcc type size. > Exercising > this a bit, there's a bug in array referencing, but this seems to > work for structs > and array allocations. The end data layout is definitely supposed to > be the > same as gcc's; ABI compatibility is a requirement, at least for us. > sizeof is computed by the FE, of course, so things like > (char*)&ld + i*sizeof(long double) > work fine. Yes, if indeed array elements (and general GEP offsets) are spaced by 12 bytes and not 10 then everything should be fine. > I'm not persuaded the approach is wrong; if we > make the padding part of the type it has to have a deterministic > value, or > bitwise comparisons don't work, and there's all those useless bytes > being > carried around. (If you experiment with gcc, you'll find those bytes > are not > deterministic; when copying long doubles, sometimes it uses fldt/fstpt > to get just 10 bytes, other times it will get 12 or 16, which may be > uninitialized. I want to avoid this sort of thing.) > > I need to fix the array-reference issue; the code that translates > getelementpr > to bytes needs to look at alignment(element type). Do you have any > other > examples that don't work? No, if arrays are spaced the same then I am happy. That said, the meanings of type size etc should probably be well documented somewhere, especially the fact that successive array elements may be space more than the size apart. Best wishes, Duncan. > On Sep 28, 2007, at 1:04 PM, Duncan Sands wrote: > > > Hi Dale, on my machine (x86-32, linux) LLVM considers long double to > > have a size of 10 bytes and an alignment of 4 bytes. GCC gives it a > > size of 12 bytes and an alignment of 4 bytes (of course only the first > > 80 bits (10 bytes) are actually used - the rest is padding). > > > > I can see several problems with a 10 byte size. > > > > First, problems that aren't related to gcc. In an array of long > > double, > > the elements may not be aligned even if the array is aligned. This is > > because the usual invariant "the size is a multiple of the > > alignment" does > > not hold for size 10, alignment 4. I'm betting that the logic for > > working > > out alignments of loads and stores in LLVM is not expecting this! > > Since > > this type only exists on x86, which is pretty lenient about unaligned > > pointer access, I suppose this might not really matter. Isn't > > unaligned > > access slower than aligned access though? Anyway, it seems to me much > > better to avoid this can of worms and have the size be a multiple > > of the > > alignment. > > > > Second, problems related to gcc. We convert long double to X86_FP80Ty > > (which I've been referring to as long double). The result is that > > the size > > of the gcc type is not equal to the size of the LLVM type. This > > causes all > > kinds of problems with arrays and pointer arithmetic. That's the > > reason > > for the check that sizes are the same (which you turned off in this > > case, > > tut tut!). For example, suppose you declare an array of long doubles, > > cast to an i8* and start moving around in it based on sizeof(long > > double). > > Well you'll end up at the wrong place because sizeof is the gcc > > size (12) > > but LLVM will have placed the elements 10 bytes apart! This also has > > knock-on effects, like LLVM arrays of long doubles having different > > lengths to the corresponding gcc arrays etc. If you think about it I > > hope you will agree that it is important to convert gcc types to LLVM > > types of the same size. > > > > By the way, are there any standards that require size to be a multiple > > of alignment? > > > > The solution I would prefer is: make getTypeSize return 12 for long > > double, > > have getTypeSizeInBits return 80 (I think this should be renamed to > > getBitsUsedByType or something like that, see APInt comments > > below). Make > > it a requirement that getTypeSize always returns a multiple of the > > alignment. > > Document that getTypeSize is the offset between successive elements > > in arrays > > of this type, or between fields in a struct; and that loads and > > stores of this > > type can write up to this many bytes. Document that > > getBitsUsedByType returns > > the minimum number of bits needed to hold all values of this type, > > and that > > this can be less
Re: [llvm-commits] Trampoline changes
On Sep 28, 2007, at 2:38 PM, Duncan Sands wrote: > Hi Chris, > >>> Also >>> 5. Within foo, you need to check that nothing too complicated is >>> done to P1, for example it isn't stored in a global or passed to >>> some other function. >> >> Actually, worse case, you could just make a trampoline in foo. >> However, you're right that this is only worth doing if there are >> calls to the fn pointer in foo. OTOH, propagating the trampoline >> creation site down to foo will allow it to be further propagated into >> functions that foo might call. > > that could be very costly. Initializing a trampoline is not very > costly. What is costly is using it and then modifying the stack > contents where the trampoline was, because you get an icache flush. > Eg: if you push the trampoline down into a function called in a loop, > then you risk calling the trampoline then dirtying that part of the > stack (after function return, due to other local variables using that > part of the stack) and thus taking a large hit on every iteration. Fair enough. :) -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] GC patches again
On Sep 28, 2007, at 2:04 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
> BTW, thank you for splitting up this patch! It makes it much easier
> to review.
No problem!
>> //===-- gc-3-collector.patch (+531) ---===//
>>
>> include/llvm/CodeGen/Collector.h (+134)
>> lib/CodeGen/Collector.cpp (+359)
>> lib/CodeGen/README.txt (+38)
>>
>> Collector is the base class for garbage collector code generators.
>> This version enhances the previous patch to add root initialization
>> as discussed here:
>
> +#ifndef LLVM_CODEGEN_GC_H
> +#define LLVM_CODEGEN_GC_H
>
> Should probably be LLVM_CODEGEN_COLLECTOR_H
>
> +
> +#include "llvm/CodeGen/CollectorMetadata.h"
> +#include
>
> plz use instead of or neither if you don't need
> them.
>
> +namespace llvm {
> +
> + class AsmPrinter;
> + class FunctionPassManager;
> + class Pass;
> + class PassManager;
> + class TargetAsmInfo;
>
> You can probably remove some of these.
>
> In Collector.cpp, it looks like you have several redundant #include's.
>
> Otherwise, looks great, plz commit.
>
>> //===-- gc-4-integration.patch (+116 -17) -===//
>>
>> In this patch, Collector winds its tendrils throughout the compiler.
>> Overhead should be minimal when disabled.
>>
>> I would particularly appreciate any feedback on this interface.
>> The primary item of concern to me is that I exposed the desired
>> collector to the compiler using a global. I have not decided on a
>> better approach. In the meantime, it works and is simple.
>
> I agree, this is not the right way to go. There are two problems:
>
> 1. introducing global data means that two instances of the codegen
> can't be made at the same time. This is not acceptable. Fixing this
> should be relatively straight forward: hang any mutable data off
> MachineFunction or MachineModuleInfo as appropriate, and any
> immutable target info off TargetMachine.
Okay.
> 2. Adding a -gc option to llc isn't what we really want.
Right. I think it should be attached to the module (perhaps via the
[sub-]target) so that the module is self-contained and magic command-
line options are not needed.
I toyed with the idea of attaching it to the function to allow linking
modules with differing collectors. That might be a good idea.
I do not think attaching it to the operations (ala EH) is wise;
different collectors could have differing requirements of the stack
layout. This precludes inlining Java into Ocaml, but the null
collector doesn't count.
> Ideally, the code generator would generate gc info for a function
> iff there is a gcroot in it. This would allow the codegen to emit
> GC code code that obviously uses it. Is there any case where the
> codegen has to do something for a function with no gcroots (or
> declared safepoints
> etc) in it?
There is.
- Ocaml needs to know the frame size at each safe point, regardless of
whether there are roots in the function.
- Sun's JVM does something analogous in that it enforces a stack
layout so that its stack walker (and HotSpot) can work.
So, generally, safe points are safe points regardless of whether the
function has roots.
-- Gordon
sent from my iPhone
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42439 - in /llvm/trunk: lib/CodeGen/AsmPrinter.cpp lib/CodeGen/IntrinsicLowering.cpp lib/Transforms/IPO/SimplifyLibCalls.cpp tools/llvm-upgrade/UpgradeLexer.cpp.cvs tools/llvm-u
Author: johannes
Date: Fri Sep 28 13:06:58 2007
New Revision: 42439
URL: http://llvm.org/viewvc/llvm-project?rev=42439&view=rev
Log:
minor long double related changes
Modified:
llvm/trunk/lib/CodeGen/AsmPrinter.cpp
llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp
llvm/trunk/lib/Transforms/IPO/SimplifyLibCalls.cpp
llvm/trunk/tools/llvm-upgrade/UpgradeLexer.cpp.cvs
llvm/trunk/tools/llvm-upgrade/UpgradeLexer.l
llvm/trunk/tools/llvm-upgrade/UpgradeLexer.l.cvs
Modified: llvm/trunk/lib/CodeGen/AsmPrinter.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/AsmPrinter.cpp?rev=42439&r1=42438&r2=42439&view=diff
==
--- llvm/trunk/lib/CodeGen/AsmPrinter.cpp (original)
+++ llvm/trunk/lib/CodeGen/AsmPrinter.cpp Fri Sep 28 13:06:58 2007
@@ -1271,6 +1271,7 @@
}
break;
case Type::FloatTyID: case Type::DoubleTyID:
+ case Type::X86_FP80TyID: case Type::FP128TyID: case Type::PPC_FP128TyID:
assert (0 && "Should have already output floating point constant.");
default:
assert (0 && "Can't handle printing this type of thing");
Modified: llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp?rev=42439&r1=42438&r2=42439&view=diff
==
--- llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp (original)
+++ llvm/trunk/lib/CodeGen/IntrinsicLowering.cpp Fri Sep 28 13:06:58 2007
@@ -794,6 +794,24 @@
Type::DoubleTy, sqrtFCache);
break;
}
+ case Intrinsic::sqrt_f80: {
+static Constant *sqrtF80Cache = 0;
+ReplaceCallWith("sqrtl", CI, CI->op_begin()+1, CI->op_end(),
+Type::X86_FP80Ty, sqrtF80Cache);
+break;
+ }
+ case Intrinsic::sqrt_f128: {
+static Constant *sqrtF128Cache = 0;
+ReplaceCallWith("sqrtl", CI, CI->op_begin()+1, CI->op_end(),
+Type::FP128Ty, sqrtF128Cache);
+break;
+ }
+ case Intrinsic::sqrt_ppcf128: {
+static Constant *sqrtppcF128Cache = 0;
+ReplaceCallWith("sqrtl", CI, CI->op_begin()+1, CI->op_end(),
+Type::PPC_FP128Ty, sqrtppcF128Cache);
+break;
+ }
}
assert(CI->use_empty() &&
Modified: llvm/trunk/lib/Transforms/IPO/SimplifyLibCalls.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/IPO/SimplifyLibCalls.cpp?rev=42439&r1=42438&r2=42439&view=diff
==
--- llvm/trunk/lib/Transforms/IPO/SimplifyLibCalls.cpp (original)
+++ llvm/trunk/lib/Transforms/IPO/SimplifyLibCalls.cpp Fri Sep 28 13:06:58 2007
@@ -1115,17 +1115,15 @@
/// @brief Perform the pow optimization.
virtual bool OptimizeCall(CallInst *ci, SimplifyLibCalls &SLC) {
const Type *Ty = cast(ci->getOperand(0))->getReturnType();
+if (Ty!=Type::FloatTy && Ty!=Type::DoubleTy)
+ return false; // FIXME long double not yet supported
Value* base = ci->getOperand(1);
Value* expn = ci->getOperand(2);
if (ConstantFP *Op1 = dyn_cast(base)) {
- if (Ty!=Type::FloatTy && Ty!=Type::DoubleTy)
-return false; // FIXME long double not yet supported
if (Op1->isExactlyValue(1.0)) // pow(1.0,x) -> 1.0
return ReplaceCallWith(ci, ConstantFP::get(Ty,
Ty==Type::FloatTy ? APFloat(1.0f) : APFloat(1.0)));
} else if (ConstantFP* Op2 = dyn_cast(expn)) {
- if (Ty!=Type::FloatTy && Ty!=Type::DoubleTy)
-return false; // FIXME long double not yet supported
if (Op2->getValueAPF().isZero()) {
// pow(x,0.0) -> 1.0
return ReplaceCallWith(ci, ConstantFP::get(Ty,
Modified: llvm/trunk/tools/llvm-upgrade/UpgradeLexer.cpp.cvs
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/tools/llvm-upgrade/UpgradeLexer.cpp.cvs?rev=42439&r1=42438&r2=42439&view=diff
==
--- llvm/trunk/tools/llvm-upgrade/UpgradeLexer.cpp.cvs (original)
+++ llvm/trunk/tools/llvm-upgrade/UpgradeLexer.cpp.cvs Fri Sep 28 13:06:58 2007
@@ -937,10 +937,11 @@
//===--===//
//
// This file implements the flex scanner for LLVM 1.9 assembly languages
files.
+// This doesn't handle long double constants, since LLVM 1.9 did not have
them.
//
//===--===*/
#define YY_NEVER_INTERACTIVE 1
-#line 28 "/Volumes/MacOS9/gcc/llvm/tools/llvm-upgrade/UpgradeLexer.l"
+#line 29 "/Volumes/MacOS9/gcc/llvm/tools/llvm-upgrade/UpgradeLexer.l"
#include "UpgradeInternals.h"
#include "llvm/Module.h"
#include
@@ -1081,7 +1082,7 @@
/* HexIntConstant - Hexadecimal constant generated by the CFE to avoid forcing
* it to deal with 64 bit numbers.
*/
-#line 1085 "UpgradeLexer.cpp"
+#line 1086 "UpgradeLexer.cpp"
/* Ma
Re: [llvm-commits] GC patches again
>> 2. Adding a -gc option to llc isn't what we really want. > > Right. I think it should be attached to the module (perhaps via the > [sub-]target) so that the module is self-contained and magic command- > line options are not needed. > > I toyed with the idea of attaching it to the function to allow linking > modules with differing collectors. That might be a good idea. > > I do not think attaching it to the operations (ala EH) is wise; > different collectors could have differing requirements of the stack > layout. This precludes inlining Java into Ocaml, but the null > collector doesn't count. Okay, I don't think we'll be able to inline code effectively that uses two different collectors. My brain hurts thinking about what to do if you get to a stop point valid in one collector but not the other etc. >> Ideally, the code generator would generate gc info for a function >> iff there is a gcroot in it. This would allow the codegen to emit >> GC code code that obviously uses it. Is there any case where the >> codegen has to do something for a function with no gcroots (or >> declared safepoints >> etc) in it? > > There is. > > - Ocaml needs to know the frame size at each safe point, regardless of > whether there are roots in the function. > > - Sun's JVM does something analogous in that it enforces a stack > layout so that its stack walker (and HotSpot) can work. > > So, generally, safe points are safe points regardless of whether the > function has roots. Another option is to mark each function that requires GC info with an attribute. The attribute could encode the GC model to use as well. This is basically the front-end telling the codegen what to do, which is better than relying on a magic command line optn. > -- Gordon > sent from my iPhone nice ;-) -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Trampoline changes
Hi Chris, > > Also > > 5. Within foo, you need to check that nothing too complicated is > > done to P1, for example it isn't stored in a global or passed to > > some other function. > > Actually, worse case, you could just make a trampoline in foo. > However, you're right that this is only worth doing if there are > calls to the fn pointer in foo. OTOH, propagating the trampoline > creation site down to foo will allow it to be further propagated into > functions that foo might call. that could be very costly. Initializing a trampoline is not very costly. What is costly is using it and then modifying the stack contents where the trampoline was, because you get an icache flush. Eg: if you push the trampoline down into a function called in a loop, then you risk calling the trampoline then dirtying that part of the stack (after function return, due to other local variables using that part of the stack) and thus taking a large hit on every iteration. Ciao, Duncan. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42453 - in /llvm/trunk: include/llvm/CodeGen/ScheduleDAG.h lib/CodeGen/SelectionDAG/ScheduleDAG.cpp lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
Author: evancheng
Date: Fri Sep 28 17:32:30 2007
New Revision: 42453
URL: http://llvm.org/viewvc/llvm-project?rev=42453&view=rev
Log:
If two instructions are both two-address code, favors (schedule closer to
terminator) the one that has a CopyToReg use. This fixes
2006-05-11-InstrSched.ll with -new-cc-modeling-scheme.
Modified:
llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h
llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp
llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
Modified: llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h?rev=42453&r1=42452&r2=42453&view=diff
==
--- llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h (original)
+++ llvm/trunk/include/llvm/CodeGen/ScheduleDAG.h Fri Sep 28 17:32:30 2007
@@ -115,7 +115,7 @@
short NumSuccsLeft; // # of succs not scheduled.
bool isTwoAddress : 1; // Is a two-address instruction.
bool isCommutable : 1; // Is a commutable instruction.
-bool hasImplicitDefs : 1; // Has implicit physical reg defs.
+bool hasPhysRegDefs : 1; // Has physreg defs that are being
used.
bool isPending: 1; // True once pending.
bool isAvailable : 1; // True once available.
bool isScheduled : 1; // True once scheduled.
@@ -129,7 +129,7 @@
SUnit(SDNode *node, unsigned nodenum)
: Node(node), InstanceNo(0), NodeNum(nodenum), Latency(0),
NumPreds(0), NumSuccs(0), NumPredsLeft(0), NumSuccsLeft(0),
-isTwoAddress(false), isCommutable(false), hasImplicitDefs(false),
+isTwoAddress(false), isCommutable(false), hasPhysRegDefs(false),
isPending(false), isAvailable(false), isScheduled(false),
CycleBound(0), Cycle(0), Depth(0), Height(0),
CopyDstRC(NULL), CopySrcRC(NULL) {}
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp?rev=42453&r1=42452&r2=42453&view=diff
==
--- llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp Fri Sep 28 17:32:30 2007
@@ -63,7 +63,7 @@
SU->Latency = Old->Latency;
SU->isTwoAddress = Old->isTwoAddress;
SU->isCommutable = Old->isCommutable;
- SU->hasImplicitDefs = Old->hasImplicitDefs;
+ SU->hasPhysRegDefs = Old->hasPhysRegDefs;
SUnitMap[Old->Node].push_back(SU);
return SU;
}
@@ -167,8 +167,6 @@
if (MainNode->isTargetOpcode()) {
unsigned Opc = MainNode->getTargetOpcode();
const TargetInstrDescriptor &TID = TII->get(Opc);
- if (TID.ImplicitDefs)
-SU->hasImplicitDefs = true;
for (unsigned i = 0; i != TID.numOperands; ++i) {
if (TID.getOperandConstraint(i, TOI::TIED_TO) != -1) {
SU->isTwoAddress = true;
@@ -185,8 +183,10 @@
for (unsigned n = 0, e = SU->FlaggedNodes.size(); n != e; ++n) {
SDNode *N = SU->FlaggedNodes[n];
- if (N->isTargetOpcode() && TII->getImplicitDefs(N->getTargetOpcode()))
-SU->hasImplicitDefs = true;
+ if (N->isTargetOpcode() &&
+ TII->getImplicitDefs(N->getTargetOpcode()) &&
+ CountResults(N) > (unsigned)TII->getNumDefs(N->getTargetOpcode()))
+SU->hasPhysRegDefs = true;
for (unsigned i = 0, e = N->getNumOperands(); i != e; ++i) {
SDNode *OpN = N->getOperand(i).Val;
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp?rev=42453&r1=42452&r2=42453&view=diff
==
--- llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp Fri Sep 28
17:32:30 2007
@@ -1144,10 +1144,26 @@
}
+/// hasCopyToRegUse - Return true if SU has a value successor that is a
+/// CopyToReg node.
+static bool hasCopyToRegUse(SUnit *SU) {
+ for (SUnit::const_succ_iterator I = SU->Succs.begin(), E = SU->Succs.end();
+ I != E; ++I) {
+if (I->isCtrl) continue;
+SUnit *SuccSU = I->Dep;
+if (SuccSU->Node && SuccSU->Node->getOpcode() == ISD::CopyToReg)
+ return true;
+ }
+ return false;
+}
+
/// AddPseudoTwoAddrDeps - If two nodes share an operand and one of them uses
/// it as a def&use operand. Add a pseudo control edge from it to the other
/// node (if it won't create a cycle) so the two-address one will be scheduled
-/// first (lower in the schedule).
+/// first (lower in the schedule). If both nodes are two-address, favor the
+/// one that has a CopyToReg use (more likely to be a loop induction update).
+/// If
[llvm-commits] [llvm] r42454 - in /llvm/trunk/docs: GettingStarted.html HowToReleaseLLVM.html
Author: tbrethou Date: Fri Sep 28 17:50:54 2007 New Revision: 42454 URL: http://llvm.org/viewvc/llvm-project?rev=42454&view=rev Log: Update how to release document. Add release version to getting started guide. Modified: llvm/trunk/docs/GettingStarted.html llvm/trunk/docs/HowToReleaseLLVM.html Modified: llvm/trunk/docs/GettingStarted.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/GettingStarted.html?rev=42454&r1=42453&r2=42454&view=diff == --- llvm/trunk/docs/GettingStarted.html (original) +++ llvm/trunk/docs/GettingStarted.html Fri Sep 28 17:50:54 2007 @@ -707,6 +707,7 @@ subdirectories of the 'tags' directory: +Release 2.1: RELEASE_21 Release 2.0: RELEASE_20 Release 1.9: RELEASE_19 Release 1.8: RELEASE_18 Modified: llvm/trunk/docs/HowToReleaseLLVM.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/HowToReleaseLLVM.html?rev=42454&r1=42453&r2=42454&view=diff == --- llvm/trunk/docs/HowToReleaseLLVM.html (original) +++ llvm/trunk/docs/HowToReleaseLLVM.html Fri Sep 28 17:50:54 2007 @@ -8,15 +8,16 @@ How To Release LLVM To The Public -NOTE: THIS DOCUMENT IS A WORK IN PROGRESS! Introduction + Release Timeline Release Process Distribution Targets Written by mailto:[EMAIL PROTECTED]">Reid Spencer, - mailto:[EMAIL PROTECTED]">John Criswell + mailto:[EMAIL PROTECTED]">John Criswell, + mailto:[EMAIL PROTECTED]">Tanya Lattner @@ -27,26 +28,46 @@ This document collects information about successfully releasing LLVM to the public. It is the release manager's guide to ensuring that a high quality - build of LLVM is released. Mostly, it's just a bunch of reminders of things to - do at release time so we don't inadvertently ship something that is utility - deficient. + build of LLVM is released. - There are three main tasks for building a release of LLVM: + The following is the basic criteria for releasing LLVM: -Create the LLVM source distribution. -Create the LLVM GCC source distribtuion. -Create a set of LLVM GCC binary distribtuions for each supported -platform. These binary distributions must include compiled versions -of the libraries found in llvm/runtime from the LLVM -source distribution created in Step 1. +Successful configure and build. +Clean 'make check'. +No regressions in the testsuite from the previous release. This may +include performance regressions for major benchmarks. +Release Timeline + + +The release manager should attempt to have a release every 3-4 months because LLVM +does time based releases (instead of feature based). The release schedule should +be roughly as follows: + +Set code freeze and branch creation date for 3 months after last release +date. Announce release schedule to the LLVM community and update the website. +Create release branch and begin release process. +Send out pre-release for first round of testing. Testing will last 7-10 days. +During the first round of testing, regressions should be found and fixed. Patches +are merged from mainline to the release branch. +Generate and send out second pre-release. Bugs found during this time will +not be fixed unless absolutely critical. Bugs introduce by patches merged in +will be fixed and if so, a 3rd round of testing is needed. +The release notes should be updated during the first and second round of +pre-release testing. +Finally, release! + + + + + Release Process @@ -54,141 +75,74 @@ Process Overview -Update Documentation -Merge Branches -Make LibDeps.txt -Settle LLVM HEAD -Tag LLVM and Create the Release Branch +Create Release Branch Update LLVM Version +Build the LLVM Source Distributions Build LLVM +Build the LLVM GCC Binary Distribution + Build RPM Packages (optional) Run 'make check' Run LLVM Test Suite -Build the LLVM Source Distributions -Build RPM Packages (optional) -Build the LLVM GCC Binary Distribution +Pre-Release Testing +Tag the LLVM Release Branch +Update Documentation +Update the LLVM Demo Page Update the LLVM Website +Announce the Release + -Update Documentation - - - Review the documentation and ensure that it is up to date. The Release Notes - must be updated to reflect bug fixes, new known issues, and changes in the - list of supported platforms. The Getting Started Guide should be updated to - reflect the new release version number tag avaiable from Subversion and - changes in basic system requirements. - - - - -Merge Branches +Create Release Branch - - Merge any work done on branches intended for release into mainline. Finish and - commit all new features or bug fixes that are scheduled to go into the - release. Work that is not to
[llvm-commits] CVS: llvm-www/www-index.html
Changes in directory llvm-www: www-index.html updated: 1.147 -> 1.148 --- Log message: 2.2 schedule --- Diffs of the changes: (+9 -1) www-index.html | 10 +- 1 files changed, 9 insertions(+), 1 deletion(-) Index: llvm-www/www-index.html diff -u llvm-www/www-index.html:1.147 llvm-www/www-index.html:1.148 --- llvm-www/www-index.html:1.147 Thu Sep 27 01:19:12 2007 +++ llvm-www/www-index.html Fri Sep 28 18:22:19 2007 @@ -116,7 +116,15 @@ Upcoming Releases - LLVM 2.2 will be released in the Dec-Jan timeframe. + LLVM 2.2 release schedule: + +Jan 16, 2008: Branch creation/Code Freezei (9PM PST). +Jan 18, 2008: First round of pre-release testing begins. +Jan 28, 2008: Pre-release testing ends. +Jan 30, 2008: Second round of pre-release testing begins. +Feb 3, 2008: Pre-release testing ends. +Feb 4, 2008: 2.2 Released. + ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] CVS: llvm-www/www-index.html
Changes in directory llvm-www: www-index.html updated: 1.148 -> 1.149 --- Log message: Fix typo. --- Diffs of the changes: (+2 -2) www-index.html |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: llvm-www/www-index.html diff -u llvm-www/www-index.html:1.148 llvm-www/www-index.html:1.149 --- llvm-www/www-index.html:1.148 Fri Sep 28 18:22:19 2007 +++ llvm-www/www-index.html Fri Sep 28 18:23:11 2007 @@ -118,12 +118,12 @@ LLVM 2.2 release schedule: -Jan 16, 2008: Branch creation/Code Freezei (9PM PST). +Jan 16, 2008: Branch creation/Code Freeze (9PM PST). Jan 18, 2008: First round of pre-release testing begins. Jan 28, 2008: Pre-release testing ends. Jan 30, 2008: Second round of pre-release testing begins. Feb 3, 2008: Pre-release testing ends. -Feb 4, 2008: 2.2 Released. +Feb 4, 2008: 2.2 released. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42457 - in /llvm/trunk: lib/CodeGen/SelectionDAG/LegalizeDAG.cpp test/CodeGen/X86/illegal-insert.ll
Author: djg
Date: Fri Sep 28 18:53:40 2007
New Revision: 42457
URL: http://llvm.org/viewvc/llvm-project?rev=42457&view=rev
Log:
Teach SplitVectorOp how to split INSERT_VECTOR_ELT.
Added:
llvm/trunk/test/CodeGen/X86/illegal-insert.ll
Modified:
llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp?rev=42457&r1=42456&r2=42457&view=diff
==
--- llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp Fri Sep 28 18:53:40 2007
@@ -5837,6 +5837,18 @@
Lo = Node->getOperand(0);
Hi = Node->getOperand(1);
break;
+ case ISD::INSERT_VECTOR_ELT: {
+SplitVectorOp(Node->getOperand(0), Lo, Hi);
+unsigned Index = cast(Node->getOperand(2))->getValue();
+SDOperand ScalarOp = Node->getOperand(1);
+if (Index < NewNumElts)
+ Lo = DAG.getNode(ISD::INSERT_VECTOR_ELT, NewVT, Lo, ScalarOp,
+ DAG.getConstant(Index, TLI.getPointerTy()));
+else
+ Hi = DAG.getNode(ISD::INSERT_VECTOR_ELT, NewVT, Hi, ScalarOp,
+ DAG.getConstant(Index - NewNumElts,
TLI.getPointerTy()));
+break;
+ }
case ISD::BUILD_VECTOR: {
SmallVector LoOps(Node->op_begin(),
Node->op_begin()+NewNumElts);
Added: llvm/trunk/test/CodeGen/X86/illegal-insert.ll
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/illegal-insert.ll?rev=42457&view=auto
==
--- llvm/trunk/test/CodeGen/X86/illegal-insert.ll (added)
+++ llvm/trunk/test/CodeGen/X86/illegal-insert.ll Fri Sep 28 18:53:40 2007
@@ -0,0 +1,18 @@
+; RUN: llvm-as %s -o - | llc -march=x86-64
+
+define <4 x double> @foo0(<4 x double> %t) {
+ %r = insertelement <4 x double> %t, double 2.3, i32 0
+ ret <4 x double> %r
+}
+define <4 x double> @foo1(<4 x double> %t) {
+ %r = insertelement <4 x double> %t, double 2.3, i32 1
+ ret <4 x double> %r
+}
+define <4 x double> @foo2(<4 x double> %t) {
+ %r = insertelement <4 x double> %t, double 2.3, i32 2
+ ret <4 x double> %r
+}
+define <4 x double> @foo3(<4 x double> %t) {
+ %r = insertelement <4 x double> %t, double 2.3, i32 3
+ ret <4 x double> %r
+}
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm-gcc-4.0] r42458 - /llvm-gcc-4.0/trunk/gcc/llvm-types.cpp
Author: dpatel
Date: Fri Sep 28 18:54:26 2007
New Revision: 42458
URL: http://llvm.org/viewvc/llvm-project?rev=42458&view=rev
Log:
Do not ignore packed member size while selecting union type.
Modified:
llvm-gcc-4.0/trunk/gcc/llvm-types.cpp
Modified: llvm-gcc-4.0/trunk/gcc/llvm-types.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm-gcc-4.0/trunk/gcc/llvm-types.cpp?rev=42458&r1=42457&r2=42458&view=diff
==
--- llvm-gcc-4.0/trunk/gcc/llvm-types.cpp (original)
+++ llvm-gcc-4.0/trunk/gcc/llvm-types.cpp Fri Sep 28 18:54:26 2007
@@ -1826,11 +1826,31 @@
SET_DECL_LLVM(Field, Idx);
const Type *TheTy = ConvertType(TREE_TYPE(Field));
+bool isPacked = false;
unsigned Size = TD.getTypeSize(TheTy);
unsigned Align = TD.getABITypeAlignment(TheTy);
+if (const StructType *STy = dyn_cast(TheTy))
+ if (STy->isPacked())
+isPacked = true;
+
adjustPaddingElement(UnionTy, TheTy);
-if (UnionTy == 0 || Align > MaxAlign
-|| (MaxAlign == Align && Size > MaxSize)) {
+
+// Select TheTy as union type if it meets one of the following criteria
+// 1) UnionTy is 0
+// 2) TheTy alignment is more then UnionTy
+// 3) TheTy size is greater than UnionTy size and TheTy alignment is equal
to UnionTy
+// 4) TheTy size is greater then UnionTy size and TheTy is packed
+bool useTheTy = false;
+if (UnionTy == 0)
+ useTheTy = true;
+else if (Align > MaxAlign)
+ useTheTy = true;
+else if (MaxAlign == Align && Size > MaxSize)
+ useTheTy = true;
+else if (isPacked && Size > MaxSize)
+ useTheTy = true;
+
+if (useTheTy) {
UnionTy = TheTy;
MaxSize = MAX(MaxSize, Size);
MaxAlign = Align;
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42458 - /llvm/trunk/test/CFrontend/2007-09-28-PackedUnionMember.c
Author: dpatel
Date: Fri Sep 28 18:54:26 2007
New Revision: 42458
URL: http://llvm.org/viewvc/llvm-project?rev=42458&view=rev
Log:
Do not ignore packed member size while selecting union type.
Added:
llvm/trunk/test/CFrontend/2007-09-28-PackedUnionMember.c
Added: llvm/trunk/test/CFrontend/2007-09-28-PackedUnionMember.c
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CFrontend/2007-09-28-PackedUnionMember.c?rev=42458&view=auto
==
--- llvm/trunk/test/CFrontend/2007-09-28-PackedUnionMember.c (added)
+++ llvm/trunk/test/CFrontend/2007-09-28-PackedUnionMember.c Fri Sep 28
18:54:26 2007
@@ -0,0 +1,37 @@
+// RUN: %llvmgcc %s -S -o -
+#pragma pack(push, 2)
+struct H {
+ unsigned long f1;
+ unsigned long f2;
+ union {
+struct opaque1 *f3;
+struct opaque2 *f4;
+struct {
+ struct opaque3 *f5;
+ unsigned short f6;
+} f7;
+ } f8;
+};
+#pragma pack(pop)
+
+struct E {
+ unsigned long f1;
+ unsigned long f2;
+};
+
+typedef long (*FuncPtr) ();
+
+extern long bork(FuncPtr handler, const struct E *list);
+
+static long hndlr()
+{
+ struct H cmd = { 4, 'fart' };
+ return 0;
+}
+void foo(void *inWindow) {
+ static const struct E events[] = {
+{ 'cmds', 1 }
+ };
+ bork(hndlr, events);
+}
+
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42460 - in /llvm/trunk: Makefile.config.in autoconf/configure.ac docs/GettingStarted.html docs/MakefileGuide.html
Author: gordon
Date: Fri Sep 28 19:42:21 2007
New Revision: 42460
URL: http://llvm.org/viewvc/llvm-project?rev=42460&view=rev
Log:
PR1601: etags not configured correctly
Resolving this by deleting vestigal etags remnants.
Modified:
llvm/trunk/Makefile.config.in
llvm/trunk/autoconf/configure.ac
llvm/trunk/docs/GettingStarted.html
llvm/trunk/docs/MakefileGuide.html
Modified: llvm/trunk/Makefile.config.in
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/Makefile.config.in?rev=42460&r1=42459&r2=42460&view=diff
==
--- llvm/trunk/Makefile.config.in (original)
+++ llvm/trunk/Makefile.config.in Fri Sep 28 19:42:21 2007
@@ -152,8 +152,6 @@
BZIP2 := @BZIP2@
DOT:= @DOT@
DOXYGEN:= @DOXYGEN@
-ETAGS := @ETAGS@
-ETAGSFLAGS := @ETAGSFLAGS@
GROFF := @GROFF@
GZIP := @GZIP@
OCAMLC := @OCAMLC@
Modified: llvm/trunk/autoconf/configure.ac
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/autoconf/configure.ac?rev=42460&r1=42459&r2=42460&view=diff
==
--- llvm/trunk/autoconf/configure.ac (original)
+++ llvm/trunk/autoconf/configure.ac Fri Sep 28 19:42:21 2007
@@ -551,15 +551,6 @@
[Define if dlopen(0) will open the symbols of the program])
fi
-dnl Check if we know how to tell etags we are using C++:
-etags_version=`$ETAGS --version 2>&1`
-case "$etags_version" in
- *[Ee]xuberant*) ETAGSFLAGS="--language-force=c++" ;;
- *GNU\ Emacs*) ETAGSFLAGS="-l c++" ;;
- *) ETAGSFLAGS="" ;;
-esac
-AC_SUBST(ETAGSFLAGS,$ETAGSFLAGS)
-
if test "$WITH_LLVMGCCDIR" = "default" ; then
LLVMGCC="llvm-gcc${EXEEXT}"
LLVMGXX="llvm-g++${EXEEXT}"
Modified: llvm/trunk/docs/GettingStarted.html
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/GettingStarted.html?rev=42460&r1=42459&r2=42460&view=diff
==
--- llvm/trunk/docs/GettingStarted.html (original)
+++ llvm/trunk/docs/GettingStarted.html Fri Sep 28 19:42:21 2007
@@ -469,7 +469,6 @@
date - print the current date/time
echo - print to standard output
egrep - extended regular expression search utility
-etags - C/C++ tag file creator for vim/emacs
find - find files/dirs in a file system
grep - regular expression search utility
gzip* - gzip command for distribution generation
Modified: llvm/trunk/docs/MakefileGuide.html
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/MakefileGuide.html?rev=42460&r1=42459&r2=42460&view=diff
==
--- llvm/trunk/docs/MakefileGuide.html (original)
+++ llvm/trunk/docs/MakefileGuide.html Fri Sep 28 19:42:21 2007
@@ -808,11 +808,6 @@
isn't one.
ECHO(configured)
Specifies the path to the echo tool for printing output.
-ETAGS(configured)
-Specifies the path to the etags tool.
-ETAGSFLAGS(configured)
-
-Provides flags to be passed to the etags tool.
EXEEXT(configured)
Provides the extension to be used on executables built by the
makefiles.
The value may be empty on platforms that do not use file extensions for
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42461 - /llvm/trunk/configure
Author: gordon
Date: Fri Sep 28 19:42:56 2007
New Revision: 42461
URL: http://llvm.org/viewvc/llvm-project?rev=42461&view=rev
Log:
Regenerate.
Modified:
llvm/trunk/configure
Modified: llvm/trunk/configure
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/configure?rev=42461&r1=42460&r2=42461&view=diff
==
--- llvm/trunk/configure (original)
+++ llvm/trunk/configure Fri Sep 28 19:42:56 2007
@@ -899,7 +899,6 @@
FFLAGS
ac_ct_F77
LIBTOOL
-ETAGSFLAGS
LLVMGCC
LLVMGXX
USE_UDIS86
@@ -10500,7 +10499,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext < conftest.$ac_ext
+ echo '#line 12646 "configure"' > conftest.$ac_ext
if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
(eval $ac_compile) 2>&5
ac_status=$?
@@ -14362,11 +14361,11 @@
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:14365: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:14364: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:14369: \$? = $ac_status" >&5
+ echo "$as_me:14368: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
@@ -14630,11 +14629,11 @@
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:14633: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:14632: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:14637: \$? = $ac_status" >&5
+ echo "$as_me:14636: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
@@ -14734,11 +14733,11 @@
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:14737: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:14736: $lt_compile\"" >&5)
(eval "$lt_compile" 2>out/conftest.err)
ac_status=$?
cat out/conftest.err >&5
- echo "$as_me:14741: \$? = $ac_status" >&5
+ echo "$as_me:14740: \$? = $ac_status" >&5
if (exit $ac_status) && test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
@@ -17186,7 +17185,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext < conftest.$ac_ext <&5)
+ (eval echo "\"\$as_me:19656: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:19661: \$? = $ac_status" >&5
+ echo "$as_me:19660: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
@@ -19758,11 +19757,11 @@
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:19761: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:19760: $lt_compile\"" >&5)
(eval "$lt_compile" 2>out/conftest.err)
ac_status=$?
cat out/conftest.err >&5
- echo "$as_me:19765: \$? = $ac_status" >&5
+ echo "$as_me:19764: \$? = $ac_status" >&5
if (exit $ac_status) && test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
@@ -21328,11 +21327,11 @@
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:21331: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:21330: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:21335: \$? = $ac_status" >&5
+ echo "$as_me:21334: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
@@ -21432,11 +21431,11 @@
-e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:21435: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:21434: $lt_compile\"" >&5)
(eval "$lt_compile" 2>out/conftest.err)
ac_status=$?
cat out/conftest.err >&5
- echo "$as_me:21439: \$? =
Re: [llvm-commits] [llvm-gcc-4.0] r42458 - /llvm-gcc-4.0/trunk/gcc/llvm-types.cpp
On 9/28/07, Devang Patel <[EMAIL PROTECTED]> wrote: > URL: http://llvm.org/viewvc/llvm-project?rev=42458&view=rev > Log: > Do not ignore packed member size while selecting union type. > Thanks! I think this should be applied to 4.2 as well. -bw ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42462 - /llvm/trunk/lib/Analysis/IPA/Andersens.cpp
Author: dannyb
Date: Fri Sep 28 19:50:40 2007
New Revision: 42462
URL: http://llvm.org/viewvc/llvm-project?rev=42462&view=rev
Log:
Switch to densemap rather than std::set
Modified:
llvm/trunk/lib/Analysis/IPA/Andersens.cpp
Modified: llvm/trunk/lib/Analysis/IPA/Andersens.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/IPA/Andersens.cpp?rev=42462&r1=42461&r2=42462&view=diff
==
--- llvm/trunk/lib/Analysis/IPA/Andersens.cpp (original)
+++ llvm/trunk/lib/Analysis/IPA/Andersens.cpp Fri Sep 28 19:50:40 2007
@@ -134,12 +134,18 @@
assert(Offset == 0 || Ty != AddressOf &&
"Offset is illegal on addressof constraints");
}
+
bool operator==(const Constraint &RHS) const {
return RHS.Type == Type
&& RHS.Dest == Dest
&& RHS.Src == Src
&& RHS.Offset == Offset;
}
+
+ bool operator!=(const Constraint &RHS) const {
+return !(*this == RHS);
+ }
+
bool operator<(const Constraint &RHS) const {
if (RHS.Type != Type)
return RHS.Type < Type;
@@ -151,6 +157,23 @@
}
};
+struct ConstraintKeyInfo {
+ static inline Constraint getEmptyKey() {
+return Constraint(Constraint::Copy, ~0UL, ~0UL, ~0UL);
+ }
+ static inline Constraint getTombstoneKey() {
+return Constraint(Constraint::Copy, ~0UL - 1, ~0UL - 1, ~0UL - 1);
+ }
+ static unsigned getHashValue(const Constraint &C) {
+return C.Src ^ C.Dest ^ C.Type ^ C.Offset;
+ }
+ static bool isEqual(const Constraint &LHS,
+ const Constraint &RHS) {
+return LHS.Type == RHS.Type && LHS.Dest == RHS.Dest
+ && LHS.Src == RHS.Src && LHS.Offset == RHS.Offset;
+ }
+};
+
// Node class - This class is used to represent a node in the constraint
// graph. Due to various optimizations, it is not always the case that
// there is a mapping from a Node to a Value. In particular, we add
@@ -1750,7 +1773,7 @@
/// replaced by their the pointer equivalence class representative.
void Andersens::RewriteConstraints() {
std::vector NewConstraints;
- std::set Seen;
+ DenseMap Seen;
PEClass2Node.clear();
PENLEClass2Node.clear();
@@ -1788,10 +1811,10 @@
C.Src = FindEquivalentNode(RHSNode, RHSLabel);
C.Dest = FindEquivalentNode(FindNode(LHSNode), LHSLabel);
if (C.Src == C.Dest && C.Type == Constraint::Copy
-|| Seen.count(C) != 0)
+|| Seen[C] == true)
continue;
-Seen.insert(C);
+Seen[C] = true;
NewConstraints.push_back(C);
}
Constraints.swap(NewConstraints);
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42367 - in /llvm/trunk: Xcode/LLVM.xcodeproj/project.pbxproj bindings/ocaml/Makefile.ocaml bindings/ocaml/bitwriter/Makefile bindings/ocaml/llvm/llvm.ml bindings/ocaml/llvm/
On Sep 28, 2007, at 16:18, Chris Lattner wrote: URL: http://llvm.org/viewvc/llvm-project?rev=42367&view=rev Log: Added C and Ocaml bindings for functions, basic blocks, and instruction creation. No support yet for instruction introspection. Also eliminated allocas from the Ocaml bindings for portability, and avoided unnecessary casts. = = --- llvm/trunk/include/llvm/CHelpers.h (original) +++ llvm/trunk/include/llvm/CHelpers.h Wed Sep 26 15:56:12 2007 Hi Gordon, I think it makes sense for CHelpers.h to move into include/llvm/ Support instead of include/llvm. What do you think? Agreed; it was on my to-do list. I'd placed it here under the assumption that there wasn't anything LLVM-specific in Support, but I later saw that I was mistaken. — Gordon ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm-gcc-4.2] r42464 - /llvm-gcc-4.2/trunk/gcc/llvm-types.cpp
Author: dpatel
Date: Fri Sep 28 20:20:11 2007
New Revision: 42464
URL: http://llvm.org/viewvc/llvm-project?rev=42464&view=rev
Log:
Do not ignore packed member size while selecting union type.
Modified:
llvm-gcc-4.2/trunk/gcc/llvm-types.cpp
Modified: llvm-gcc-4.2/trunk/gcc/llvm-types.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/llvm-types.cpp?rev=42464&r1=42463&r2=42464&view=diff
==
--- llvm-gcc-4.2/trunk/gcc/llvm-types.cpp (original)
+++ llvm-gcc-4.2/trunk/gcc/llvm-types.cpp Fri Sep 28 20:20:11 2007
@@ -1836,11 +1836,31 @@
SetFieldIndex(Field, 0);
const Type *TheTy = ConvertType(TREE_TYPE(Field));
+bool isPacked = false;
unsigned Size = TD.getTypeSize(TheTy);
unsigned Align = TD.getABITypeAlignment(TheTy);
+if (const StructType *STy = dyn_cast(TheTy))
+ if (STy->isPacked())
+isPacked = true;
+
adjustPaddingElement(UnionTy, TheTy);
-if (UnionTy == 0 || Align > MaxAlign
-|| (MaxAlign == Align && Size > MaxSize)) {
+
+// Select TheTy as union type if it meets one of the following criteria
+// 1) UnionTy is 0
+// 2) TheTy alignment is more then UnionTy
+// 3) TheTy size is greater than UnionTy size and TheTy alignment is equal
to UnionTy
+// 4) TheTy size is greater then UnionTy size and TheTy is packed
+bool useTheTy = false;
+if (UnionTy == 0)
+ useTheTy = true;
+else if (Align > MaxAlign)
+ useTheTy = true;
+else if (MaxAlign == Align && Size > MaxSize)
+ useTheTy = true;
+else if (isPacked && Size > MaxSize)
+ useTheTy = true;
+
+if (useTheTy) {
UnionTy = TheTy;
MaxSize = MAX(MaxSize, Size);
MaxAlign = Align;
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42465 - in /llvm/trunk: include/llvm/CHelpers.h include/llvm/Support/CHelpers.h lib/Bitcode/Writer/BitWriter.cpp lib/VMCore/Core.cpp
Author: gordon
Date: Fri Sep 28 20:38:42 2007
New Revision: 42465
URL: http://llvm.org/viewvc/llvm-project?rev=42465&view=rev
Log:
Demoting CHelpers.h to include/llvm/Support.
Added:
llvm/trunk/include/llvm/Support/CHelpers.h
- copied unchanged from r42459, llvm/trunk/include/llvm/CHelpers.h
Removed:
llvm/trunk/include/llvm/CHelpers.h
Modified:
llvm/trunk/lib/Bitcode/Writer/BitWriter.cpp
llvm/trunk/lib/VMCore/Core.cpp
Removed: llvm/trunk/include/llvm/CHelpers.h
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CHelpers.h?rev=42464&view=auto
==
--- llvm/trunk/include/llvm/CHelpers.h (original)
+++ llvm/trunk/include/llvm/CHelpers.h (removed)
@@ -1,104 +0,0 @@
-//===-- Support/CHelpers.h - Utilities for writing C bindings
-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file was developed by the LLVM research group and is distributed under
-// the University of Illinois Open Source License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// These opaque reference<-->pointer conversions are shorter and more tightly
-// typed than writing the casts by hand in C bindings. In assert builds, they
-// will do type checking.
-//
-//===--===//
-
-#ifndef LLVM_SUPPORT_CHELPERS_H
-#define LLVM_SUPPORT_CHELPERS_H
-
-#include "llvm/Module.h"
-#include "llvm/Type.h"
-#include "llvm/Value.h"
-
-typedef struct LLVMOpaqueModule *LLVMModuleRef;
-typedef struct LLVMOpaqueType *LLVMTypeRef;
-typedef struct LLVMOpaqueValue *LLVMValueRef;
-
-namespace llvm {
- /// Opaque module conversions
- ///
- inline Module *unwrap(LLVMModuleRef M) {
-return reinterpret_cast(M);
- }
-
- inline LLVMModuleRef wrap(Module *M) {
-return reinterpret_cast(M);
- }
-
- /// Opaque type conversions
- ///
- inline Type *unwrap(LLVMTypeRef Ty) {
-return reinterpret_cast(Ty);
- }
-
- template
- inline T *unwrap(LLVMTypeRef Ty) {
-return cast(unwrap(Ty));
- }
-
- inline Type **unwrap(LLVMTypeRef* Tys) {
-return reinterpret_cast(Tys);
- }
-
- inline LLVMTypeRef wrap(const Type *Ty) {
-return reinterpret_cast(const_cast(Ty));
- }
-
- inline LLVMTypeRef *wrap(const Type **Tys) {
-return reinterpret_cast(const_cast(Tys));
- }
-
- /// Opaque value conversions
- ///
- inline Value *unwrap(LLVMValueRef Val) {
-return reinterpret_cast(Val);
- }
-
- template
- inline T *unwrap(LLVMValueRef Val) {
-return cast(unwrap(Val));
- }
-
- inline Value **unwrap(LLVMValueRef *Vals) {
-return reinterpret_cast(Vals);
- }
-
- template
- inline T **unwrap(LLVMValueRef *Vals, unsigned Length) {
-#if DEBUG
-for (LLVMValueRef *I = Vals, E = Vals + Length; I != E; ++I)
- cast(*I);
-#endif
-return reinterpret_cast(Vals);
- }
-
- inline LLVMValueRef wrap(const Value *Val) {
-return reinterpret_cast(const_cast(Val));
- }
-
- inline LLVMValueRef *wrap(const Value **Vals) {
-return reinterpret_cast(const_cast(Vals));
- }
-
- /// Basic block conversions
- ///
- inline BasicBlock *unwrap(LLVMBasicBlockRef BBRef) {
-return reinterpret_cast(BBRef);
- }
-
- inline LLVMBasicBlockRef wrap(const BasicBlock *BB) {
-return reinterpret_cast(const_cast(BB));
- }
-}
-
-#endif
Modified: llvm/trunk/lib/Bitcode/Writer/BitWriter.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Bitcode/Writer/BitWriter.cpp?rev=42465&r1=42464&r2=42465&view=diff
==
--- llvm/trunk/lib/Bitcode/Writer/BitWriter.cpp (original)
+++ llvm/trunk/lib/Bitcode/Writer/BitWriter.cpp Fri Sep 28 20:38:42 2007
@@ -8,8 +8,8 @@
//===--===//
#include "llvm-c/BitWriter.h"
-#include "llvm/CHelpers.h"
#include "llvm/Bitcode/ReaderWriter.h"
+#include "llvm/Support/CHelpers.h"
#include
using namespace llvm;
Modified: llvm/trunk/lib/VMCore/Core.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/VMCore/Core.cpp?rev=42465&r1=42464&r2=42465&view=diff
==
--- llvm/trunk/lib/VMCore/Core.cpp (original)
+++ llvm/trunk/lib/VMCore/Core.cpp Fri Sep 28 20:38:42 2007
@@ -14,10 +14,10 @@
#include "llvm-c/Core.h"
#include "llvm/Bitcode/ReaderWriter.h"
-#include "llvm/CHelpers.h"
#include "llvm/Constants.h"
#include "llvm/DerivedTypes.h"
#include "llvm/GlobalVariable.h"
+#include "llvm/Support/CHelpers.h"
#include "llvm/Support/LLVMBuilder.h"
#include "llvm/TypeSymbolTable.h"
#include
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r42367 - in /llvm/trunk: Xcode/LLVM.xcodeproj/project.pbxproj bindings/ocaml/Makefile.ocaml bindings/ocaml/bitwriter/Makefile bindings/ocaml/llvm/llvm.ml bindings/ocaml/llvm/
On 2007-09-28, at 21:02, Gordon Henriksen wrote: On Sep 28, 2007, at 16:18, Chris Lattner wrote: URL: http://llvm.org/viewvc/llvm-project?rev=42367&view=rev Log: Added C and Ocaml bindings for functions, basic blocks, and instruction creation. No support yet for instruction introspection. Also eliminated allocas from the Ocaml bindings for portability, and avoided unnecessary casts. == --- llvm/trunk/include/llvm/CHelpers.h (original) +++ llvm/trunk/include/llvm/CHelpers.h Wed Sep 26 15:56:12 2007 Hi Gordon, I think it makes sense for CHelpers.h to move into include/llvm/ Support instead of include/llvm. What do you think? Agreed; it was on my to-do list. I'd placed it here under the assumption that there wasn't anything LLVM-specific in Support, but I later saw that I was mistaken. Done. I suppose I could get rid of this header entirely by putting these silly things in llvm-c protected by #ifdef __cplusplus. Too nutty? — Gordon ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r42466 - in /llvm/trunk: include/llvm/CodeGen/Collector.h lib/CodeGen/Collector.cpp lib/CodeGen/README.txt
Author: gordon
Date: Fri Sep 28 21:13:43 2007
New Revision: 42466
URL: http://llvm.org/viewvc/llvm-project?rev=42466&view=rev
Log:
Collector is the base class for garbage collection code generators.
This version enhances the previous patch to add root initialization
as discussed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070910/053455.html
Collector gives its subclasses control over generic algorithms:
unsigned NeededSafePoints; //< Bitmask of required safe points.
bool CustomReadBarriers; //< Default is to insert loads.
bool CustomWriteBarriers; //< Default is to insert stores.
bool CustomRoots; //< Default is to pass through to backend.
bool InitRoots;//< If set, roots are nulled during lowering.
It also has callbacks which collectors can hook:
/// If any of the actions are set to Custom, this is expected to
/// be overriden to create a transform to lower those actions to
/// LLVM IR.
virtual Pass *createCustomLoweringPass() const;
/// beginAssembly/finishAssembly - Emit module metadata as
/// assembly code.
virtual void beginAssembly(Module &M, std::ostream &OS,
AsmPrinter &AP,
const TargetAsmInfo &TAI) const;
virtual void finishAssembly(Module &M,
CollectorModuleMetadata &CMM,
std::ostream &OS, AsmPrinter &AP,
const TargetAsmInfo &TAI) const;
Various other independent algorithms could be implemented, but were
not necessary for the initial two collectors. Some examples are
listed here:
http://llvm.org/docs/GarbageCollection.html#collector-algos
Added:
llvm/trunk/include/llvm/CodeGen/Collector.h
llvm/trunk/lib/CodeGen/Collector.cpp
Modified:
llvm/trunk/lib/CodeGen/README.txt
Added: llvm/trunk/include/llvm/CodeGen/Collector.h
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/Collector.h?rev=42466&view=auto
==
--- llvm/trunk/include/llvm/CodeGen/Collector.h (added)
+++ llvm/trunk/include/llvm/CodeGen/Collector.h Fri Sep 28 21:13:43 2007
@@ -0,0 +1,133 @@
+//===-- llvm/CodeGen/Collector.h - Garbage collection ---*- C++
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file was developed by Gordon Henriksen and is distributed under
+// the University of Illinois Open Source License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// GCInfo records sufficient information about a machine function to enable
+// accurate garbage collectors. Specifically:
+//
+// - Safe points
+// Garbage collection is only possible at certain points in code. Code
+// generators should record points:
+//
+// - At and after any call to a subroutine
+// - Before returning from the current function
+// - Before backwards branches (loops)
+//
+// - Roots
+// When a reference to a GC-allocated object exists on the stack, it must be
+// stored in an alloca registered with llvm.gcoot.
+//
+// This generic information should used by ABI-specific passes to emit support
+// tables for the runtime garbage collector.
+//
+// GCSafePointPass identifies the GC safe points in the machine code. (Roots
are
+// identified in SelectionDAGISel.)
+//
+//===--===//
+
+#ifndef LLVM_CODEGEN_COLLECTOR_H
+#define LLVM_CODEGEN_COLLECTOR_H
+
+#include "llvm/CodeGen/CollectorMetadata.h"
+#include
+
+namespace llvm {
+
+ class AsmPrinter;
+ class FunctionPassManager;
+ class PassManager;
+ class TargetAsmInfo;
+
+
+ /// Collector describes a garbage collector's code generation requirements,
+ /// and provides overridable hooks for those needs which cannot be abstractly
+ /// described.
+ class Collector {
+ protected:
+unsigned NeededSafePoints; //< Bitmask of required safe points.
+bool CustomReadBarriers; //< Default is to insert loads.
+bool CustomWriteBarriers; //< Default is to insert stores.
+bool CustomRoots; //< Default is to pass through to backend.
+bool InitRoots;//< If set, roots are nulled during lowering.
+
+/// If any of the actions are set to Custom, this is expected to be
+/// overriden to create a transform to lower those actions to LLVM IR.
+virtual Pass *createCustomLoweringPass() const;
+
+ public:
+Collector();
+
+virtual ~Collector();
+
+
+/// True if this collector requires safe points of any kind. By default,
+/// none are recorded.
+bool needsSafePoints() const { return NeededSafePoints != 0; }
+
+/// True if the collector requires the given kind of safe point. By
default,
+/// none are recorded.
+bool needsSafePoint(GC::PointKind Kind) const {
+ return (Nee
[llvm-commits] [llvm] r42467 - /llvm/trunk/lib/CodeGen/README.txt
Author: gordon Date: Fri Sep 28 21:23:08 2007 New Revision: 42467 URL: http://llvm.org/viewvc/llvm-project?rev=42467&view=rev Log: This is done already. Modified: llvm/trunk/lib/CodeGen/README.txt Modified: llvm/trunk/lib/CodeGen/README.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/README.txt?rev=42467&r1=42466&r2=42467&view=diff == --- llvm/trunk/lib/CodeGen/README.txt (original) +++ llvm/trunk/lib/CodeGen/README.txt Fri Sep 28 21:23:08 2007 @@ -151,13 +151,6 @@ //===-===// -Instead of unconditionally inserting a null initializer for every GC root when -Collector::InitRoots is set, the collector infrastructure should get a little -bit smarter and perform a trivial DSE of the initial basic block up to the -first safe point. - -//===-===// - With a copying garbage collector, derived pointers must not be retained across collector safe points; the collector could move the objects and invalidate the derived pointer. This is bad enough in the first place, but safe points can ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [test-suite] r42468 - /test-suite/trunk/Makefile.programs
Author: evancheng Date: Fri Sep 28 22:06:21 2007 New Revision: 42468 URL: http://llvm.org/viewvc/llvm-project?rev=42468&view=rev Log: x86 llcbeta back to -regalloc=local -fast Modified: test-suite/trunk/Makefile.programs Modified: test-suite/trunk/Makefile.programs URL: http://llvm.org/viewvc/llvm-project/test-suite/trunk/Makefile.programs?rev=42468&r1=42467&r2=42468&view=diff == --- test-suite/trunk/Makefile.programs (original) +++ test-suite/trunk/Makefile.programs Fri Sep 28 22:06:21 2007 @@ -221,7 +221,7 @@ LLCBETAOPTION := -sched=simple endif ifeq ($(ARCH),x86) -LLCBETAOPTION := -new-cc-modeling-scheme +LLCBETAOPTION := -regalloc=local -fast #-disable-rematerialization #-disable-fp-elim #-regalloc=bigblock -fast ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
