[llvm-commits] [llvm] r46922 - /llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
Author: void Date: Sun Feb 10 02:10:24 2008 New Revision: 46922 URL: http://llvm.org/viewvc/llvm-project?rev=46922&view=rev Log: Return "(c1 + c2)" instead of yet another ADD node (which made this a no-op). Modified: llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp Modified: llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp?rev=46922&r1=46921&r2=46922&view=diff == --- llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp (original) +++ llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp Sun Feb 10 02:10:24 2008 @@ -923,7 +923,7 @@ return N1; // fold (add c1, c2) -> c1+c2 if (N0C && N1C) -return DAG.getNode(ISD::ADD, VT, N0, N1); +return DAG.getConstant(N0C->getValue() + N1C->getValue(), VT); // canonicalize constant to RHS if (N0C && !N1C) return DAG.getNode(ISD::ADD, VT, N1, N0); ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46923 - /llvm/trunk/docs/ReleaseNotes.html
Author: lattner Date: Sun Feb 10 02:17:19 2008 New Revision: 46923 URL: http://llvm.org/viewvc/llvm-project?rev=46923&view=rev Log: final set of major updates Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=46923&r1=46922&r2=46923&view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Sun Feb 10 02:17:19 2008 @@ -138,10 +138,15 @@ bits) and on Darwin PPC/PPC64 (where it is 128 bits). In previous LLVM releases, llvm-gcc silently mapped long double to double. -Gordon rewrote most of the Accurate Garbage -Collection code in the code generator, making the generated code more -efficient and adding support for the Ocaml garbage collector metadata -format. +Gordon Henriksen rewrote most of the Accurate Garbage Collection code in the code generator, making the +generated code more efficient and adding support for the Ocaml garbage collector +metadata format. + +Christopher Lamb contributed support for multiple address spaces in LLVM +IR. This is useful for supporting targets that have 'near' vs 'far' pointers, +'RAM' vs 'ROM' pointers, or that have non-local memory that can be accessed with +special instructions. LLVM now includes a new set of detailed tutorials, which explain how to implement a @@ -151,6 +156,44 @@ +LLVM Core Improvements + + + +New features include: + + + +Gordon contributed support for C and Ocaml Bindings for the basic LLVM IR +construction routines as well as several other auxiliary APIs. + +Anton added readnone/readonly attributes for modeling function side effects. +Duncan hooked up GCC's pure/const attributes to use them and enhanced mod/ref +analysis to use them. + +Devang added LLVMFoldingBuilder, a version of LLVMBuilder that implicitly +simplifies the code as it is constructed. + +Ted Kremenek added a framework for generic object serialization to bitcode +files. This support is only used by clang right now for ASTs but is extensible +and could be used for serializing arbitrary other data into bitcode files. + +Duncan improved TargetData to distinguish between the size/alignment of a +type in a register, in memory according to the platform ABI, and in memory when +we have a choice. + +Duncan moved parameter attributes off of FunctionType and onto functions +and calls. This makes it much easier to add attributes to a function in a +transformation pass. + +Dan Gohman added support for vector sin, cos, and pow intrinsics. + + + + + + + Code Generator Improvements @@ -211,15 +254,15 @@ -In addition to a huge array of bug fixes and minor performance tweaks, LLVM -2.2 supports a few major enhancements: +In addition to a huge array of bug fixes and minor performance tweaks, the +LLVM 2.2 optimizers support a few major enhancements: Daniel Berlin and Curtis Dunham rewrote Andersen's alias analysis to be -several orders of magnitude faster, implemented Offline Variable Substitution -and Lazy Cycle Detection. Note that Andersen's is not enabled in llvm-gcc by -default. +several orders of magnitude faster, and implemented Offline Variable +Substitution and Lazy Cycle Detection. Note that Andersen's is not enabled in +llvm-gcc by default, but can be accessed through 'opt'. Dan Gohman contributed several enhancements to Loop Strength Reduction (LSR) to make it more aggressive with SSE intrinsics. @@ -240,48 +283,23 @@ -New features include: +New target-specific features include: -Evan X86 now models EFLAGS in instructions. -Evan: If conversion on by default for ARM. -Bruno: MIPS PIC support. -Arnold Schwaighofer: X86 tail call support. -Dale darwin/x86-64 and darwin/ppc eh -Evan: darwin/x86 debug info, improvements at -O0? - - - - - - -LLVM Core Improvements - - - -New features include: - - - -Devang added LLVMFoldingBuilder. -Dan added support for vector sin, cos, and pow intrinsics. -Ted added a framework for generic object serialization to bitcode files, -only used by clang right now for ASTs but could be used for other -stuff. -Duncan fixed TargetData to distinguish between the size/alignment of a type -in a register, in memory according to the platform ABI, and in memory when -we have a choice. -Duncan moved parameter attributes off of function type and onto functions -and calls, which makes it much easier to add attributes to a function in a -transformation. -Christopher Lamb: Multiple address spaces. -Gordon: C and Ocaml Bindings - -Anton added readnone/readonly attributes for modeling function side effects -and Duncan hooked up GCC's pure/const attributes to use them and enhanced alias -analysis to use them. - +Evan contributed support to the X86 backend to model the mod/ref behavior +of the EFLAGS register explicitly in all instructions. This gives more
[llvm-commits] [llvm] r46924 - /llvm/trunk/docs/ReleaseNotes.html
Author: lattner Date: Sun Feb 10 02:18:42 2008 New Revision: 46924 URL: http://llvm.org/viewvc/llvm-project?rev=46924&view=rev Log: validation fixes Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=46924&r1=46923&r2=46924&view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Sun Feb 10 02:18:42 2008 @@ -152,6 +152,8 @@ href="tutorial/index.html">tutorials, which explain how to implement a language with LLVM and shows how to use several important APIs. + + @@ -697,7 +699,7 @@ http://jigsaw.w3.org/css-validator/check/referer";>http://jigsaw.w3.org/css-validator/images/vcss"; alt="Valid CSS!"> http://validator.w3.org/check/referer";>http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!" /> + src="http://www.w3.org/Icons/valid-html401"; alt="Valid HTML 4.01!"> http://llvm.org/";>LLVM Compiler Infrastructure Last modified: $Date$ ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46925 - /llvm/trunk/docs/ReleaseNotes.html
Author: lattner Date: Sun Feb 10 02:19:35 2008 New Revision: 46925 URL: http://llvm.org/viewvc/llvm-project?rev=46925&view=rev Log: remove the in progress marker. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=46925&r1=46924&r2=46925&view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Sun Feb 10 02:19:35 2008 @@ -23,8 +23,6 @@ Written by the http://llvm.org";>LLVM Team -THIS IS A WORK IN PROGRESS FOR THE LLVM 2.2 -RELEASE ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46926 - in /llvm/trunk/lib/CodeGen/SelectionDAG: LegalizeTypes.h LegalizeTypesExpand.cpp SelectionDAG.cpp
Author: baldrick
Date: Sun Feb 10 04:08:52 2008
New Revision: 46926
URL: http://llvm.org/viewvc/llvm-project?rev=46926&view=rev
Log:
Add truncate and AssertZext result expansion.
Modified:
llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypes.h
llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypesExpand.cpp
llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypes.h
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypes.h?rev=46926&r1=46925&r2=46926&view=diff
==
--- llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypes.h (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypes.h Sun Feb 10 04:08:52 2008
@@ -209,6 +209,8 @@
void ExpandResult_ANY_EXTEND (SDNode *N, SDOperand &Lo, SDOperand &Hi);
void ExpandResult_ZERO_EXTEND(SDNode *N, SDOperand &Lo, SDOperand &Hi);
void ExpandResult_SIGN_EXTEND(SDNode *N, SDOperand &Lo, SDOperand &Hi);
+ void ExpandResult_AssertZext (SDNode *N, SDOperand &Lo, SDOperand &Hi);
+ void ExpandResult_TRUNCATE (SDNode *N, SDOperand &Lo, SDOperand &Hi);
void ExpandResult_BIT_CONVERT(SDNode *N, SDOperand &Lo, SDOperand &Hi);
void ExpandResult_SIGN_EXTEND_INREG(SDNode *N, SDOperand &Lo, SDOperand &Hi);
void ExpandResult_LOAD (LoadSDNode *N, SDOperand &Lo, SDOperand &Hi);
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypesExpand.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypesExpand.cpp?rev=46926&r1=46925&r2=46926&view=diff
==
--- llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypesExpand.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeTypesExpand.cpp Sun Feb 10
04:08:52 2008
@@ -60,6 +60,8 @@
case ISD::ANY_EXTEND: ExpandResult_ANY_EXTEND(N, Lo, Hi); break;
case ISD::ZERO_EXTEND: ExpandResult_ZERO_EXTEND(N, Lo, Hi); break;
case ISD::SIGN_EXTEND: ExpandResult_SIGN_EXTEND(N, Lo, Hi); break;
+ case ISD::AssertZext: ExpandResult_AssertZext(N, Lo, Hi); break;
+ case ISD::TRUNCATE:ExpandResult_TRUNCATE(N, Lo, Hi); break;
case ISD::BIT_CONVERT: ExpandResult_BIT_CONVERT(N, Lo, Hi); break;
case ISD::SIGN_EXTEND_INREG: ExpandResult_SIGN_EXTEND_INREG(N, Lo, Hi);
break;
case ISD::LOAD:ExpandResult_LOAD(cast(N), Lo, Hi); break;
@@ -202,6 +204,34 @@
}
}
+void DAGTypeLegalizer::ExpandResult_AssertZext(SDNode *N,
+ SDOperand &Lo, SDOperand &Hi) {
+ GetExpandedOp(N->getOperand(0), Lo, Hi);
+ MVT::ValueType NVT = Lo.getValueType();
+ MVT::ValueType EVT = cast(N->getOperand(1))->getVT();
+ unsigned NVTBits = MVT::getSizeInBits(NVT);
+ unsigned EVTBits = MVT::getSizeInBits(EVT);
+
+ if (NVTBits < EVTBits) {
+Hi = DAG.getNode(ISD::AssertZext, NVT, Hi,
+ DAG.getValueType(MVT::getIntegerType(EVTBits - NVTBits)));
+ } else {
+Lo = DAG.getNode(ISD::AssertZext, NVT, Lo, DAG.getValueType(EVT));
+// The high part must be zero, make it explicit.
+Hi = DAG.getConstant(0, NVT);
+ }
+}
+
+void DAGTypeLegalizer::ExpandResult_TRUNCATE(SDNode *N,
+ SDOperand &Lo, SDOperand &Hi) {
+ MVT::ValueType NVT = TLI.getTypeToTransformTo(N->getValueType(0));
+ Lo = DAG.getNode(ISD::TRUNCATE, NVT, N->getOperand(0));
+ Hi = DAG.getNode(ISD::SRL, N->getOperand(0).getValueType(), N->getOperand(0),
+ DAG.getConstant(MVT::getSizeInBits(NVT),
+ TLI.getShiftAmountTy()));
+ Hi = DAG.getNode(ISD::TRUNCATE, NVT, Hi);
+}
+
void DAGTypeLegalizer::ExpandResult_BIT_CONVERT(SDNode *N,
SDOperand &Lo, SDOperand &Hi) {
// Lower the bit-convert to a store/load from the stack, then expand the
load.
Modified: llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp?rev=46926&r1=46925&r2=46926&view=diff
==
--- llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp (original)
+++ llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp Sun Feb 10 04:08:52
2008
@@ -2018,6 +2018,7 @@
"Cannot *_EXTEND_INREG FP types");
assert(MVT::getSizeInBits(EVT) <= MVT::getSizeInBits(VT) &&
"Not extending!");
+if (VT == EVT) return N1; // noop assertion.
break;
}
case ISD::SIGN_EXTEND_INREG: {
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm-gcc-4.2] r46927 - /llvm-gcc-4.2/trunk/gcc/gcc.c
Author: wmat
Date: Sun Feb 10 04:41:01 2008
New Revision: 46927
URL: http://llvm.org/viewvc/llvm-project?rev=46927&view=rev
Log:
Revert commits: r46886, r46860, r46858. Restore proper working of -emit-llvm
and --emit-llvm options on, at
least, Linux/x86.
Modified:
llvm-gcc-4.2/trunk/gcc/gcc.c
Modified: llvm-gcc-4.2/trunk/gcc/gcc.c
URL:
http://llvm.org/viewvc/llvm-project/llvm-gcc-4.2/trunk/gcc/gcc.c?rev=46927&r1=46926&r2=46927&view=diff
==
--- llvm-gcc-4.2/trunk/gcc/gcc.c (original)
+++ llvm-gcc-4.2/trunk/gcc/gcc.c Sun Feb 10 04:41:01 2008
@@ -825,12 +825,12 @@
/* LLVM LOCAL begin */
static const char *llvm_options =
#ifdef ENABLE_LLVM
-"%{O4|Zemit-llvm:%{S:-emit-llvm} \
+"%{O4|emit-llvm:%{S:-emit-llvm} \
%{!S:-emit-llvm-bc \
%{c: %W{o*} %{!o*:-o %b%w.o}} \
%{!c:-o %d%w%u%O}}}"
#else
- "%{Zemit-llvm:%e--emit-llvm is not supported in this configuration.}"
+ "%{emit-llvm:%e--emit-llvm is not supported in this configuration.}"
#endif
;
/* LLVM LOCAL end */
@@ -860,10 +860,10 @@
static const char *invoke_as =
#ifdef AS_NEEDS_DASH_FOR_PIPED_INPUT
/* LLVM LOCAL */
-"%{!O4:%{!Zemit-llvm:%{!S:-o %|.s |\n as %(asm_options) %|.s %A }}}";
+"%{!O4:%{!emit-llvm:%{!S:-o %|.s |\n as %(asm_options) %|.s %A }}}";
#else
/* LLVM LOCAL */
-"%{!O4:%{!Zemit-llvm:%{!S:-o %|.s |\n as %(asm_options) %m.s %A }}}";
+"%{!O4:%{!emit-llvm:%{!S:-o %|.s |\n as %(asm_options) %m.s %A }}}";
#endif
/* Some compilers have limits on line lengths, and the multilib_select
@@ -1226,8 +1226,6 @@
const char *const replacements;
} target_option_translations[] =
{
- /* LLVM LOCAL */
- {"-emit-llvm", "-Zemit-llvm"},
TARGET_OPTION_TRANSLATE_TABLE,
{ 0, 0 }
};
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46928 - /llvm/trunk/docs/ReleaseNotes.html
Author: baldrick Date: Sun Feb 10 07:40:55 2008 New Revision: 46928 URL: http://llvm.org/viewvc/llvm-project?rev=46928&view=rev Log: Add some Ada info and correct a few buglets. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=46928&r1=46927&r2=46928&view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Sun Feb 10 07:40:55 2008 @@ -97,7 +97,7 @@ LLVM 2.1, llvm-gcc 4.2 was beta). Since LLVM 2.1, the llvm-gcc 4.2 front-end has made leaps and bounds and is now at least as good as 4.0 in virtually every area, and is better in several areas (for example, exception handling -correctness, support for Ada and FORTRAN). We strongly recommend that you +correctness, support for Ada and Fortran). We strongly recommend that you migrate from llvm-gcc 4.0 to llvm-gcc 4.2 in this release cycle because LLVM 2.2 is the last release that will support llvm-gcc 4.0: LLVM 2.3 will only support the llvm-gcc 4.2 front-end. @@ -126,11 +126,11 @@ Scott Michel contributed an SPU backend, which generates code for the vector coprocessors on the Cell processor. (Status?) -llvm-gcc 4.2 has significantly improved support for the GCC Ada (GNAT) and -FORTRAN (gfortran) frontends. Duncan has the llvm-gcc 4.2 GNAT front-end -supporting almost all of the ACATS testsuite (except 2 tests?). The llvm-gcc -4.2 gfortran front-end supports a broad range of FORTRAN code, but does http://llvm.org/PR1971";>not support EQUIVALENCE yet. +Anton and Duncan significantly improved llvm-gcc 4.2 support for the GCC Ada +(GNAT) and Fortran (gfortran) front-ends. These front-ends should still be considered +experimental however: see the list of known problems. +The release binaries do not contain either front-end: they need to be built from +source (the Ada front-end only builds on x86-32 linux). Dale contributed full support for long double on x86/x86-64 (where it is 80 bits) and on Darwin PPC/PPC64 (where it is 128 bits). In previous LLVM @@ -168,7 +168,7 @@ construction routines as well as several other auxiliary APIs. Anton added readnone/readonly attributes for modeling function side effects. -Duncan hooked up GCC's pure/const attributes to use them and enhanced mod/ref +Duncan hooked up GCC's pure/const attributes to them and enhanced mod/ref analysis to use them. Devang added LLVMFoldingBuilder, a version of LLVMBuilder that implicitly @@ -182,7 +182,7 @@ type in a register, in memory according to the platform ABI, and in memory when we have a choice. -Duncan moved parameter attributes off of FunctionType and onto functions +Reid moved parameter attributes off of FunctionType and onto functions and calls. This makes it much easier to add attributes to a function in a transformation pass. @@ -211,7 +211,7 @@ and backward dominator computation. Dan added support for emitting debug information with .file and .loc -directives on that support it, instead of emitting large tables in the .s +directives on platforms that support it, instead of emitting large tables in the .s file. Evan extended the DAG scheduler to model physical register dependencies @@ -300,6 +300,7 @@ details?). Evan contributed several enhancements to Darwin/x86 debug information, and improvements at -O0 (details?). +Duncan added x86-64 support for trampolines (pointers to nested functions). @@ -528,6 +529,7 @@ http://llvm.org/PR1658";>The C backend violates the ABI of common C++ programs, preventing intermixing between C++ compiled by the CBE and C++ code compiled with LLC or native compilers. +The C backend does not support all exception handling constructs. @@ -538,6 +540,52 @@ Known problems with the C front-end + + + Known problems with the Ada front-end + + + +The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature +technology and problems should be expected. + +The Ada front-end currently only builds on x86-32. This is mainly due +to lack of trampoline support (pointers to nested functions) on other platforms, +however it http://llvm.org/PR2006";>also fails to build on x86-64 +which does support trampolines. +The Ada front-end http://llvm.org/PR2007";>fails to bootstrap. +Workaround: configure with --disable-bootstrap. +The c380004 and http://llvm.org/PR2010";>c393010 ACATS tests +fail (c380004 also fails with gcc-4.2 mainline). +Many gcc specific Ada tests continue to crash the compiler. +The -E binder option (exception backtraces) +http://llvm.org/PR1982";>does not work and will result in programs +crashing if an exception is raised. Workaround: do not use -E. +Only discrete types http://llvm.org/PR1981";>are allowed to start +or finish at a non-byte offset in a record. Workaround: do not pack records +or use representati
[llvm-commits] [llvm] r46929 - /llvm/trunk/docs/ReleaseNotes.html
Author: lattner Date: Sun Feb 10 11:52:05 2008 New Revision: 46929 URL: http://llvm.org/viewvc/llvm-project?rev=46929&view=rev Log: close an li tag Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=46929&r1=46928&r2=46929&view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Sun Feb 10 11:52:05 2008 @@ -130,7 +130,7 @@ (GNAT) and Fortran (gfortran) front-ends. These front-ends should still be considered experimental however: see the list of known problems. The release binaries do not contain either front-end: they need to be built from -source (the Ada front-end only builds on x86-32 linux). +source (the Ada front-end only builds on x86-32 linux). Dale contributed full support for long double on x86/x86-64 (where it is 80 bits) and on Darwin PPC/PPC64 (where it is 128 bits). In previous LLVM ___ 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.151 -> 1.152 --- Log message: link to all the tutorials. --- 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.151 llvm-www/www-index.html:1.152 --- llvm-www/www-index.html:1.151 Thu Jan 24 02:12:47 2008 +++ llvm-www/www-index.html Sun Feb 10 12:10:42 2008 @@ -79,8 +79,8 @@ Want to learn more? -If you'd like to learn more about LLVM, take a look at LLVM Tutorial and the extensive +If you'd like to learn more about LLVM, take a look at the LLVM Tutorials and the extensive documentation for LLVM. In particular, all of the tools distributed with LLVM are described in the LLVM Command Guide. If you're interested in what ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46931 - /llvm/trunk/lib/Target/X86/X86InstrSSE.td
Author: sampo
Date: Sun Feb 10 12:47:57 2008
New Revision: 46931
URL: http://llvm.org/viewvc/llvm-project?rev=46931&view=rev
Log:
xmm0 variable blends
Modified:
llvm/trunk/lib/Target/X86/X86InstrSSE.td
Modified: llvm/trunk/lib/Target/X86/X86InstrSSE.td
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86InstrSSE.td?rev=46931&r1=46930&r2=46931&view=diff
==
--- llvm/trunk/lib/Target/X86/X86InstrSSE.td (original)
+++ llvm/trunk/lib/Target/X86/X86InstrSSE.td Sun Feb 10 12:47:57 2008
@@ -3223,7 +3223,7 @@
def rri : SS4AI,
OpSize {
@@ -3232,7 +3232,7 @@
def rmi : SS4AI,
@@ -3254,6 +3254,31 @@
int_x86_sse41_mpsadbw, 0>;
+/// SS41I_binop_rmi_int - SSE 4.1 binary operator with immediate
+let isTwoAddress = 1 in {
+ multiclass SS41I_ternary_int opc, string OpcodeStr, Intrinsic IntId>
{
+def rr0 : SS48I,
+OpSize;
+
+def rm0 : SS48I, OpSize;
+ }
+}
+
+defm BLENDVPD : SS41I_ternary_int<0x15, "blendvpd",
int_x86_sse41_blendvpd>;
+defm BLENDVPS : SS41I_ternary_int<0x14, "blendvps",
int_x86_sse41_blendvps>;
+defm PBLENDVB : SS41I_ternary_int<0x10, "pblendvb",
int_x86_sse41_pblendvb>;
+
+
multiclass SS41I_binop_rm_int8 opc, string OpcodeStr, Intrinsic IntId>
{
def rr : SS48Ihttp://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] patches for the JIT and Kaleidoscope tutorials
On Jan 30, 2008, at 12:51 PM, Sam Bishop wrote: > I have been working my way through the JIT and Kaleidoscope > tutorials in my > (minuscule) spare time. Thanks again for writing them! I have > attached a > patch containing some minor changes, ranging from spelling and > grammar fixes > to adding a "Next: " hyperlink to the bottom > of each > page. > > Every page has been given the "next link" treatment, but otherwise > I'm only > half way through the Kaleidoscope tutorial. I will send a follow-on > patch > if time permits. Applied, thanks Sam! http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080204/058073.html -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r46108 - in /llvm/trunk: lib/Transforms/IPO/ArgumentPromotion.cpp test/Transforms/ArgumentPromotion/attrs.ll
On Jan 17, 2008, at 1:45 AM, Duncan Sands wrote: > Hi Chris, > >> Fix arg promotion to propagate the correct attrs on the calls to >> promoted functions. This is important for varargs calls in >> particular. Thanks to duncan for providing a great testcase. > > you forgot about attributes on the function return value. Hi Duncan, I've lost the context for this, do you remember what this was about? -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r46930 - in /llvm/trunk: Xcode/LLVM.xcodeproj/ docs/ include/llvm/CodeGen/ include/llvm/Target/ lib/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/ lib/Target/ARM/ lib/Target/
On Feb 10, 2008, at 10:45 AM, Dan Gohman wrote: > Author: djg > Date: Sun Feb 10 12:45:23 2008 > New Revision: 46930 > > URL: http://llvm.org/viewvc/llvm-project?rev=46930&view=rev > Log: > Rename MRegisterInfo to TargetRegisterInfo. Whoa, excellent! We've needed this for a long time, -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46932 - /llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp
Author: lattner
Date: Sun Feb 10 13:05:37 2008
New Revision: 46932
URL: http://llvm.org/viewvc/llvm-project?rev=46932&view=rev
Log:
Fix scalarrepl to not 'miscompile' undefined code, part #2.
This fixes the store case, my previous patch just fixed the load
case. rdar://5707076.
Modified:
llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp
Modified: llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp?rev=46932&r1=46931&r2=46932&view=diff
==
--- llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp (original)
+++ llvm/trunk/lib/Transforms/Scalar/ScalarReplAggregates.cpp Sun Feb 10
13:05:37 2008
@@ -1150,7 +1150,7 @@
// then 'or' into place.
Value *SV = SI->getOperand(0);
const Type *AllocaType = NewAI->getType()->getElementType();
- if (SV->getType() == AllocaType) {
+ if (SV->getType() == AllocaType && Offset == 0) {
// All is well.
} else if (const VectorType *PTy = dyn_cast(AllocaType)) {
Value *Old = new LoadInst(NewAI, NewAI->getName()+".in", SI);
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46933 - in /llvm/trunk/docs/tutorial: JITTutorial1.html JITTutorial2.html LangImpl1.html LangImpl2.html LangImpl3.html LangImpl4.html LangImpl5.html LangImpl6.html LangImpl7.htm
Author: lattner
Date: Sun Feb 10 13:11:04 2008
New Revision: 46933
URL: http://llvm.org/viewvc/llvm-project?rev=46933&view=rev
Log:
Various updates from Sam Bishop:
"I have been working my way through the JIT and Kaleidoscope tutorials in my
(minuscule) spare time. Thanks again for writing them! I have attached a
patch containing some minor changes, ranging from spelling and grammar fixes
to adding a "Next: " hyperlink to the bottom of each
page.
Every page has been given the "next link" treatment, but otherwise I'm only
half way through the Kaleidoscope tutorial. I will send a follow-on patch
if time permits."
Modified:
llvm/trunk/docs/tutorial/JITTutorial1.html
llvm/trunk/docs/tutorial/JITTutorial2.html
llvm/trunk/docs/tutorial/LangImpl1.html
llvm/trunk/docs/tutorial/LangImpl2.html
llvm/trunk/docs/tutorial/LangImpl3.html
llvm/trunk/docs/tutorial/LangImpl4.html
llvm/trunk/docs/tutorial/LangImpl5.html
llvm/trunk/docs/tutorial/LangImpl6.html
llvm/trunk/docs/tutorial/LangImpl7.html
Modified: llvm/trunk/docs/tutorial/JITTutorial1.html
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/tutorial/JITTutorial1.html?rev=46933&r1=46932&r2=46933&view=diff
==
--- llvm/trunk/docs/tutorial/JITTutorial1.html (original)
+++ llvm/trunk/docs/tutorial/JITTutorial1.html Sun Feb 10 13:11:04 2008
@@ -25,7 +25,7 @@
-For starters, lets consider a relatively straightforward function that
takes three integer parameters and returns an arithmetic combination of them.
This is nice and simple, especially since it involves no control flow:
+For starters, let's consider a relatively straightforward function that
takes three integer parameters and returns an arithmetic combination of them.
This is nice and simple, especially since it involves no control flow:
@@ -86,7 +86,7 @@
-The first segment is pretty simple: it creates an LLVM âmodule.â In
LLVM, a module represents a single unit of code that is to be processed
together. A module contains things like global variables and function
declarations and implementations. Here, weâve declared a
makeLLVMModule() function to do the real work of creating the
module. Donât worry, weâll be looking at that one next!
+The first segment is pretty simple: it creates an LLVM âmodule.â In
LLVM, a module represents a single unit of code that is to be processed
together. A module contains things like global variables, function
declarations, and implementations. Here weâve declared a
makeLLVMModule() function to do the real work of creating the
module. Donât worry, weâll be looking at that one next!
The second segment runs the LLVM module verifier on our newly created
module. While this probably isnât really necessary for a simple module like
this one, itâs always a good idea, especially if youâre generating LLVM IR
based on some input. The verifier will print an error message if your LLVM
module is malformed in any way.
@@ -106,7 +106,7 @@
- Constant* c = mod->getOrInsertFunction("mul_add",
+ Constant* c = mod->getOrInsertFunction("mul_add",
/*ret type*/ IntegerType::get(32),
/*args*/ IntegerType::get(32),
IntegerType::get(32),
@@ -114,31 +114,31 @@
/*varargs terminated with null*/ NULL);
Function* mul_add = cast(c);
- mul_add->setCallingConv(CallingConv::C);
+ mul_add->setCallingConv(CallingConv::C);
-We construct our Function by calling
getOrInsertFunction() on our module, passing in the name, return
type, and argument types of the function. In the case of our
mul_add function, that means one 32-bit integer for the return
value, and three 32-bit integers for the arguments.
+We construct our Function by calling
getOrInsertFunction() on our module, passing in the name, return
type, and argument types of the function. In the case of our
mul_add function, that means one 32-bit integer for the return
value and three 32-bit integers for the arguments.
-You'll notice that getOrInsertFunction doesn't actually return
a Function*. This is because, if the function already existed,
but with a different prototype, getOrInsertFunction will return a
cast of the existing function to the desired prototype. Since we know that
there's not already a mul_add function, we can safely just cast
c to a Function*.
+You'll notice that getOrInsertFunction() doesn't actually
return a Function*. This is because
getOrInsertFunction() will return a cast of the existing function
if the function already existed with a different prototype. Since we know that
there's not already a mul_add function, we can safely just cast
c to a Function*.
In addition, we set the calling convention for our new function to be the C
calling convention. This isnât strictly nec
Re: [llvm-commits] [llvm] r46827 - memoperands #1
On Feb 6, 2008, at 2:27 PM, Dan Gohman wrote:
> URL: http://llvm.org/viewvc/llvm-project?rev=46827&view=rev
> Log:
> Create a new class, MemOperand, for describing memory references
> in the backend. Introduce a new SDNode type, MemOperandSDNode, for
> holding a MemOperand in the SelectionDAG IR, and add a MemOperand
> list to MachineInstr, and code to manage them. Remove the offset
> field from SrcValueSDNode; uses of SrcValueSDNode that were using
> it are all all using MemOperandSDNode now.
>
> Also, begin updating some getLoad and getStore calls to use the
> PseudoSourceValue objects.
>
> Most of this was written by Florian Brander, some
> reorganization and updating to TOT by me.
>
> Re-apply the memory operand changes, with a fix for the static
> initializer problem, a minor tweak to the way the
> DAGISelEmitter finds load/store nodes, and a renaming of the
> new PseudoSourceValue objects.
This is very nice work guys. Some thoughts:
class MemOperand {
Should this be named MachineMemOperand, or something like that, for
consistency?
unsigned int Flags;
int Offset;
int Size;
unsigned int Alignment;
Is 32 bits sufficient for offset information? Are there any targets
that can do reg+largeoffset?
If you store Alignment in power-of-two form, you can make it be a
short, and then pack flags+alignment into the same word.
Instead of Size here, would it make sense to store an MVT? That would
seem to capture strictly more information, thought I'm not sure if
it's directly useful right now.
Is the Value* always required to have llvm::PointerType if nonnull?
If so, it would be useful to add a comment stating that. When we have
more support for alternate address spaces in the backend, this could
be a useful invariant to have.
In MachineInstr, is there any semantics associated with the ordering
of memoperands? Are there any current targets that have instructions
with multiple memoperands?
> Modified: llvm/trunk/include/llvm/CodeGen/SelectionDAG.h
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/CodeGen/SelectionDAG.h?rev=46585&r1=46584&r2=46585&view=diff
>
> =
> =
> =
> =
> =
> =
> =
> =
> ==
> --- llvm/trunk/include/llvm/CodeGen/SelectionDAG.h (original)
> +++ llvm/trunk/include/llvm/CodeGen/SelectionDAG.h Wed Jan 30
> 18:25:39 2008
> @@ -381,8 +381,12 @@
> SDOperand getIndexedStore(SDOperand OrigStoe, SDOperand Base,
>SDOperand Offset, ISD::MemIndexedMode AM);
>
> + // getSrcValue - Construct a node to track a Value* through the
> backend.
> + SDOperand getSrcValue(const Value *v);
> +
> + // getMemOperand - Construct a node to track a memory reference
> + // through the backend.
> + SDOperand getMemOperand(const MemOperand &MO);
What is the difference between a SrcValueSDNode and a MemOperandSDNode
now? Is the former a special case of the later?
> +/// MemOperandSDNode - An SDNode that holds a MemOperand. This is
> +/// used to represent a reference to memory after ISD::LOAD
> +/// and ISD::STORE have been lowered.
> +///
> +class MemOperandSDNode : public SDNode {
> + virtual void ANCHOR(); // Out-of-line virtual method to give
> class a home.
> +protected:
> + friend class SelectionDAG;
> + /// Create a MemOperand node
> + explicit MemOperandSDNode(MemOperand mo)
This should probably take 'mo' by const reference to avoid a copy.
> @@ -1546,6 +1573,10 @@
> /// isUnindexed - Return true if this is NOT a pre/post inc/dec
> load/store.
> bool isUnindexed() const { return AddrMode == ISD::UNINDEXED; }
>
> + /// getMemOperand - Return a MemOperand object describing the
> memory
> + /// reference performed by this load or store.
> + MemOperand getMemOperand() const;
Would it make sense to merge all the fields in LSBaseSDNode into a
MemOperand ivar?
> =
> =
> =
> =
> =
> =
> =
> =
> ==
> --- llvm/trunk/lib/CodeGen/PseudoSourceValue.cpp (original)
> +++ llvm/trunk/lib/CodeGen/PseudoSourceValue.cpp Wed Feb 6 16:27:42
> 2008
> @@ -0,0 +1,41 @@
...
> +namespace llvm {
> + static ManagedStatic PSVs;
> +
> + const PseudoSourceValue &PseudoSourceValue::getFixedStack()
> { return (*PSVs)[0]; }
> + const PseudoSourceValue &PseudoSourceValue::getStack() { return
> (*PSVs)[1]; }
> + const PseudoSourceValue &PseudoSourceValue::getGOT() { return
> (*PSVs)[2]; }
> + const PseudoSourceValue &PseudoSourceValue::getConstantPool()
> { return (*PSVs)[3]; }
> + const PseudoSourceValue &PseudoSourceValue::getJumpTable()
> { return (*PSVs)[4]; }
> +
80 col violations, but otherwise looks nice.
> Modified: llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp?rev=46827&r1=46826&r2=46827&view=diff
>
> =
> =
> =
> =
> =
> =
> =
> =
>
Re: [llvm-commits] [llvm] r46108 - in /llvm/trunk: lib/Transforms/IPO/ArgumentPromotion.cpp test/Transforms/ArgumentPromotion/attrs.ll
> > you forgot about attributes on the function return value. > > I've lost the context for this, do you remember what this was about? I fixed it for you already :) D. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r46108 - in /llvm/trunk: lib/Transforms/IPO/ArgumentPromotion.cpp test/Transforms/ArgumentPromotion/attrs.ll
On Feb 10, 2008, at 11:56 AM, Duncan Sands wrote: >>> you forgot about attributes on the function return value. >> >> I've lost the context for this, do you remember what this was about? > > I fixed it for you already :) Ahh, thanks :) :) -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r46934 - /llvm/trunk/docs/ReleaseNotes.html
> maybe c380004 can be hyperlinked too? There's not really much point: this is not an llvm-gcc problem. I don't plan to open a PR for it, so there's nothing to link to. Ciao, Duncan. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46934 - /llvm/trunk/docs/ReleaseNotes.html
Author: ggreif Date: Sun Feb 10 14:08:16 2008 New Revision: 46934 URL: http://llvm.org/viewvc/llvm-project?rev=46934&view=rev Log: corrected some spellings maybe c380004 can be hyperlinked too? Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=46934&r1=46933&r2=46934&view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Sun Feb 10 14:08:16 2008 @@ -138,7 +138,7 @@ Gordon Henriksen rewrote most of the Accurate Garbage Collection code in the code generator, making the -generated code more efficient and adding support for the Ocaml garbage collector +generated code more efficient and adding support for the OCaml garbage collector metadata format. Christopher Lamb contributed support for multiple address spaces in LLVM @@ -164,7 +164,7 @@ -Gordon contributed support for C and Ocaml Bindings for the basic LLVM IR +Gordon contributed support for C and OCaml Bindings for the basic LLVM IR construction routines as well as several other auxiliary APIs. Anton added readnone/readonly attributes for modeling function side effects. @@ -291,7 +291,7 @@ of the EFLAGS register explicitly in all instructions. This gives more freedom to the scheduler, and is a more explicit way to model the instructions. Dale contributed support for exception handling on Darwin/x86-64 and -Darwin/ppc. +Darwin/PPC. Evan turned on if-conversion by default for ARM, allowing LLVM to take advantage of its predication features. Bruno added PIC support to the MIPS backend, fixed many bugs and improved ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r46827 - MemOperands #2/2
On Feb 6, 2008, at 2:27 PM, Dan Gohman wrote:
> URL: http://llvm.org/viewvc/llvm-project?rev=46827&view=rev
> Log:
> Re-apply the memory operand changes, with a fix for the static
> initializer problem, a minor tweak to the way the
> DAGISelEmitter finds load/store nodes, and a renaming of the
> new PseudoSourceValue objects.
Continuing the review:
> =
> =
> =
> =
> =
> =
> =
> =
> ==
> --- llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp (original)
> +++ llvm/trunk/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp Wed Feb 6
> 16:27:42 2008
> @@ -277,15 +277,27 @@
> return N;
> }
>
> +/// CountOperands - The inputs to target nodes have any actual
> inputs first,
> +/// followed by optional memory operands chain operand, then flag
> operands.
Strictly speaking, a node can have at most one flag operand. This
comment isn't your bug, but it would be nice to fix it :)
>
> +/// Compute the number of actual operands that will go into the
> machine istr.
istr -> instr or instruction? Also, double space before 'will'.
>
> unsigned ScheduleDAG::CountOperands(SDNode *Node) {
> unsigned N = Node->getNumOperands();
> while (N && Node->getOperand(N - 1).getValueType() == MVT::Flag)
> --N;
> if (N && Node->getOperand(N - 1).getValueType() == MVT::Other)
> --N; // Ignore chain if it exists.
> + while (N && MemOperandSDNode::classof(Node->getOperand(N - 1).Val))
Instead of calling classof, please use:
N && isa(...)
>
> +--N; // Ignore MemOperand nodes
> + return N;
> +}
> +
> +/// CountMemOperands - Find the index of the last MemOperandSDNode
> operand
> +unsigned ScheduleDAG::CountMemOperands(SDNode *Node) {
Please rename this method. The name implies that it returns the
number of mem operands, not the index of the last one.
> =
> =
> =
> =
> =
> =
> =
> =
> ==
> --- llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp (original)
> +++ llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp Wed Feb 6
> 16:27:42 2008
> @@ -3503,6 +3535,26 @@
> TheGlobal = const_cast(GA);
> }
>
> +/// getMemOperand - Return a MemOperand object describing the memory
> +/// reference performed by this load or store.
> +MemOperand LSBaseSDNode::getMemOperand() const {
> + int Size = (MVT::getSizeInBits(getMemoryVT()) + 7) >> 3;
> + int Flags =
> +getOpcode() == ISD::LOAD ? MemOperand::MOLoad :
> MemOperand::MOStore;
> + if (IsVolatile) Flags |= MemOperand::MOVolatile;
> +
> + // Check if the load references a frame index, and does not have
> + // an SV attached.
> + const FrameIndexSDNode *FI =
> +dyn_cast(getBasePtr().Val);
> + if (!getSrcValue() && FI)
> +return MemOperand(&PseudoSourceValue::getFixedStack(), Flags,
> + FI->getIndex(), Size, Alignment);
> + else
> +return MemOperand(getSrcValue(), Flags,
> + getSrcValueOffset(), Size, Alignment);
This logic seems correct, but would be more clear (at least to me) if
written as:
if (getSrcValue() || !FI)
> +return MemOperand(getSrcValue(), Flags,
> + getSrcValueOffset(), Size, Alignment);
else
> + if (!getSrcValue() && FI)
> +return MemOperand(&PseudoSourceValue::getFixedStack(), Flags,
> + FI->getIndex(), Size, Alignment);
It would be even easier if LSBaseSDNode just contained a memoperand to
return by const reference though :)
> =
> =
> =
> =
> =
> =
> =
> =
> ==
> --- llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp (original)
> +++ llvm/trunk/lib/Target/PowerPC/PPCISelLowering.cpp Wed Feb 6
> 16:27:42 2008
> @@ -2199,9 +2203,11 @@
> Op.getOperand(0));
>
> // STD the extended value into the stack slot.
> + MemOperand MO(&PseudoSourceValue::getFixedStack(),
> +MemOperand::MOStore, FrameIdx, 8, 8);
Ah, this is interesting. I had to go look at the header file to make
sure this is correct: wouldn't it make sense for the offset/index to
be passed after the Value*? I would expect to see something like:
> + MemOperand MO(&PseudoSourceValue::getFixedStack(), FrameIdx,
> +MemOperand::MOStore, 8, 8);
instead of splitting the two. If MemOperand stored an MVT instead of
a size, it would make it a bit more clear what was going on, because
the magic constants would be reduced:
> + MemOperand MO(&PseudoSourceValue::getFixedStack(), FrameIdx,
> +MemOperand::MOStore, MVT::i64, 8);
etc.
> =
> =
> =
> =
> =
> =
> =
> =
> ==
> --- llvm/trunk/utils/TableGen/DAGISelEmitter.cpp (original)
> +++ llvm/trunk/utils/TableGen/DAGISelEmitter.cpp Wed Feb 6 16:27:42
> 2008
> @@ -313,6 +313,12 @@
> std::vector > OrigChains;
> std::set Duplicate
Re: [llvm-commits] Fix for PR1798 (ScalarEvolution)
On Feb 9, 2008, at 9:26 AM, Wojciech Matyjewicz wrote: > Hi, > > I've attached an updated version of the patch. It is ready for using > support for APInts in the code generator, but currently it doesn't > rely > on this feature. I've added a hack that rounds up the computation > bitwidth to power of 2 (only these bitwidths are allowed: 1, 2, ..., > 64). Hack is visible and very easy to remove in future. > > Is it safe to commit it now? The patch looks good to me. Nicholas, can you please review it also? If Nicholas likes it, please commit, -Chris ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Fix for PR1798 (ScalarEvolution)
Chris Lattner wrote: > On Feb 9, 2008, at 9:26 AM, Wojciech Matyjewicz wrote: > >> Hi, >> >> I've attached an updated version of the patch. It is ready for using >> support for APInts in the code generator, but currently it doesn't >> rely >> on this feature. I've added a hack that rounds up the computation >> bitwidth to power of 2 (only these bitwidths are allowed: 1, 2, ..., >> 64). Hack is visible and very easy to remove in future. >> >> Is it safe to commit it now? > > The patch looks good to me. Nicholas, can you please review it also? > If Nicholas likes it, please commit, Just one question, + const IntegerType *ExTy = IntegerType::get(std::max(DividendBits, 32U)); why the max of DividendBits and 32? If for whatever reason we think we need only 16 bits for the computation, why expand it to 32? Nick ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Fix for PR1798 (ScalarEvolution)
Chris Lattner wrote: > > The patch looks good to me. Nicholas, can you please review it also? > If Nicholas likes it, please commit, IIRC, Nicholas reviewed the previous version. Nick, the only difference is the hack to round the necessary bitwitdh up to 32 or 64 in the beginning of BinomialCoefficient() function. Wojtek ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Fix for PR1798 (ScalarEvolution)
Nick Lewycky wrote: > > Just one question, > > + const IntegerType *ExTy = IntegerType::get(std::max(DividendBits, 32U)); > > why the max of DividendBits and 32? If for whatever reason we think we > need only 16 bits for the computation, why expand it to 32? We compute the divisor of the BC formula using 32-bit arithmetic. Hence, this is the lower bound for the bitwitdh of the division, and the dividend as well. After your question, I have realized that 32 bits for the divisor may be too much... Using "only" 16 bits would allow us to handle AddRecs up to length 8. If you agree 16 is a safe bitwidth, I'll change it. However, the maximum operation you ask about will still be necessary. The other way is to compute the dividend with the minimum bitwidth (say, 8), and then zero-extend it to 16 (32 withouth the above change) if necessary just before performing the division. But wouldn't it be an overkill? Wojtek ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] Fix for PR1798 (ScalarEvolution)
Wojciech Matyjewicz wrote: > Nick Lewycky wrote: >> Just one question, >> >> + const IntegerType *ExTy = IntegerType::get(std::max(DividendBits, 32U)); >> >> why the max of DividendBits and 32? If for whatever reason we think we >> need only 16 bits for the computation, why expand it to 32? > > We compute the divisor of the BC formula using 32-bit arithmetic. Hence, > this is the lower bound for the bitwitdh of the division, and the > dividend as well. That makes sense. > After your question, I have realized that 32 bits for the divisor may be > too much... Using "only" 16 bits would allow us to handle AddRecs up to > length 8. If you agree 16 is a safe bitwidth, I'll change it. However, > the maximum operation you ask about will still be necessary. Optimally, we'd use APInt and get the right length up front, but there's no need for that to hold up this patch. Nick ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r46916 - /llvm/trunk/lib/Target/PowerPC/PPCTargetAsmInfo.cpp
Any idea what the differences mean? .rodata.cst4 makes it possible to be merged? Was there a reason to change it or than to match gcc? Thanks, Evan On Feb 9, 2008, at 4:03 PM, Nick Lewycky wrote: > Author: nicholas > Date: Sat Feb 9 18:03:54 2008 > New Revision: 46916 > > URL: http://llvm.org/viewvc/llvm-project?rev=46916&view=rev > Log: > Match GCC's behaviour for these sections. > > Modified: >llvm/trunk/lib/Target/PowerPC/PPCTargetAsmInfo.cpp > > Modified: llvm/trunk/lib/Target/PowerPC/PPCTargetAsmInfo.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCTargetAsmInfo.cpp?rev=46916&r1=46915&r2=46916&view=diff > > = > = > = > = > = > = > = > = > == > --- llvm/trunk/lib/Target/PowerPC/PPCTargetAsmInfo.cpp (original) > +++ llvm/trunk/lib/Target/PowerPC/PPCTargetAsmInfo.cpp Sat Feb 9 > 18:03:54 2008 > @@ -92,8 +92,8 @@ > CommentString = "#"; > GlobalPrefix = ""; > PrivateGlobalPrefix = ""; > - ConstantPoolSection = "\t.section .rodata.cst4\t"; > - JumpTableDataSection = ".section .rodata.cst4"; > + ConstantPoolSection = "\t.section .rodata\t"; > + JumpTableDataSection = ".section .rodata"; > CStringSection = "\t.section\t.rodata"; > StaticCtorsSection = ".section\t.ctors,\"aw\",@progbits"; > StaticDtorsSection = ".section\t.dtors,\"aw\",@progbits"; > > > ___ > 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] r46922 - /llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
What is this fixing? I would expect SelectionDAG to constant evaluating it to a constant node? Evan On Feb 10, 2008, at 12:10 AM, Bill Wendling wrote: > Author: void > Date: Sun Feb 10 02:10:24 2008 > New Revision: 46922 > > URL: http://llvm.org/viewvc/llvm-project?rev=46922&view=rev > Log: > Return "(c1 + c2)" instead of yet another ADD node (which made this a > no-op). > > Modified: >llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp > > Modified: llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp?rev=46922&r1=46921&r2=46922&view=diff > > = > = > = > = > = > = > = > = > == > --- llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp (original) > +++ llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp Sun Feb 10 > 02:10:24 2008 > @@ -923,7 +923,7 @@ > return N1; > // fold (add c1, c2) -> c1+c2 > if (N0C && N1C) > -return DAG.getNode(ISD::ADD, VT, N0, N1); > +return DAG.getConstant(N0C->getValue() + N1C->getValue(), VT); > // canonicalize constant to RHS > if (N0C && !N1C) > return DAG.getNode(ISD::ADD, VT, N1, N0); > > > ___ > 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] r46949 - in /llvm/trunk/lib/Target: TargetSelectionDAG.td X86/README-SSE.txt X86/X86ISelLowering.cpp X86/X86ISelLowering.h X86/X86InstrSSE.td
Author: sampo
Date: Sun Feb 10 22:19:36 2008
New Revision: 46949
URL: http://llvm.org/viewvc/llvm-project?rev=46949&view=rev
Log:
Enable SSE4 codegen and pattern matching.
Add some notes to the README.
Modified:
llvm/trunk/lib/Target/TargetSelectionDAG.td
llvm/trunk/lib/Target/X86/README-SSE.txt
llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
llvm/trunk/lib/Target/X86/X86ISelLowering.h
llvm/trunk/lib/Target/X86/X86InstrSSE.td
Modified: llvm/trunk/lib/Target/TargetSelectionDAG.td
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/TargetSelectionDAG.td?rev=46949&r1=46948&r2=46949&view=diff
==
--- llvm/trunk/lib/Target/TargetSelectionDAG.td (original)
+++ llvm/trunk/lib/Target/TargetSelectionDAG.td Sun Feb 10 22:19:36 2008
@@ -181,8 +181,8 @@
def SDTVecExtract : SDTypeProfile<1, 2, [ // vector extract
SDTCisEltOfVec<0, 1>, SDTCisPtrTy<2>
]>;
-def SDTVecInsert : SDTypeProfile<1, 2, [ // vector insert
- SDTCisEltOfVec<1, 0>, SDTCisPtrTy<2>
+def SDTVecInsert : SDTypeProfile<1, 3, [ // vector insert
+ SDTCisEltOfVec<2, 1>, SDTCisSameAs<0, 1>, SDTCisPtrTy<3>
]>;
class SDCallSeqStart constraints> :
Modified: llvm/trunk/lib/Target/X86/README-SSE.txt
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/README-SSE.txt?rev=46949&r1=46948&r2=46949&view=diff
==
--- llvm/trunk/lib/Target/X86/README-SSE.txt (original)
+++ llvm/trunk/lib/Target/X86/README-SSE.txt Sun Feb 10 22:19:36 2008
@@ -761,3 +761,23 @@
instead of in target independent code.
//===-===//
+
+Non-SSE4 insert into 16 x i8 is atrociously bad.
+
+//===-===//
+
+<2 x i64> extract is substantially worse than <2 x f64>, even if the
destination
+is memory.
+
+//===-===//
+
+SSE4 extract-to-mem ops aren't being pattern matched because of the AssertZext
+sitting between the truncate and the extract.
+
+//===-===//
+
+INSERTPS can match any insert (extract, imm1), imm2 for 4 x float, and insert
+any number of 0.0 simultaneously. Currently we only use it for simple
+insertions.
+
+See comments in LowerINSERT_VECTOR_ELT_SSE4.
Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
URL:
http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86ISelLowering.cpp?rev=46949&r1=46948&r2=46949&view=diff
==
--- llvm/trunk/lib/Target/X86/X86ISelLowering.cpp (original)
+++ llvm/trunk/lib/Target/X86/X86ISelLowering.cpp Sun Feb 10 22:19:36 2008
@@ -678,6 +678,33 @@
setOperationAction(ISD::SELECT, MVT::v2f64, Custom);
setOperationAction(ISD::SELECT, MVT::v2i64, Custom);
}
+
+ if (Subtarget->hasSSE41()) {
+// FIXME: Do we need to handle scalar-to-vector here?
+setOperationAction(ISD::MUL,MVT::v4i32, Legal);
+
+// i8 and i16 vectors are custom , because the source register and source
+// source memory operand types are not the same width. f32 vectors are
+// custom since the immediate controlling the insert encodes additional
+// information.
+setOperationAction(ISD::INSERT_VECTOR_ELT, MVT::v16i8, Custom);
+setOperationAction(ISD::INSERT_VECTOR_ELT, MVT::v8i16, Custom);
+setOperationAction(ISD::INSERT_VECTOR_ELT, MVT::v4i32, Legal);
+setOperationAction(ISD::INSERT_VECTOR_ELT, MVT::v4f32, Custom);
+
+setOperationAction(ISD::EXTRACT_VECTOR_ELT, MVT::v16i8, Custom);
+setOperationAction(ISD::EXTRACT_VECTOR_ELT, MVT::v8i16, Custom);
+setOperationAction(ISD::EXTRACT_VECTOR_ELT, MVT::v4i32, Legal);
+setOperationAction(ISD::EXTRACT_VECTOR_ELT, MVT::v4f32, Legal);
+
+if (Subtarget->is64Bit()) {
+ setOperationAction(ISD::INSERT_VECTOR_ELT, MVT::v2i64, Legal);
+ setOperationAction(ISD::INSERT_VECTOR_ELT, MVT::v2f64, Legal);
+
+ setOperationAction(ISD::EXTRACT_VECTOR_ELT, MVT::v2i64, Legal);
+ setOperationAction(ISD::EXTRACT_VECTOR_ELT, MVT::v2f64, Legal);
+}
+ }
// We want to custom lower some of our intrinsics.
setOperationAction(ISD::INTRINSIC_WO_CHAIN, MVT::Other, Custom);
@@ -3655,10 +3682,34 @@
}
SDOperand
+X86TargetLowering::LowerEXTRACT_VECTOR_ELT_SSE4(SDOperand Op,
+SelectionDAG &DAG) {
+ MVT::ValueType VT = Op.getValueType();
+ if (MVT::getSizeInBits(VT) == 8) {
+SDOperand Extract = DAG.getNode(X86ISD::PEXTRB, MVT::i32,
+Op.getOperand(0), Op.getOperand(1));
+SDOperand Assert = DAG.getNode(ISD::AssertZext, MVT::i32, Extract,
+DAG
[llvm-commits] [llvm] r46948 - /llvm/trunk/lib/Target/PowerPC/README.txt
Author: sampo Date: Sun Feb 10 22:16:09 2008 New Revision: 46948 URL: http://llvm.org/viewvc/llvm-project?rev=46948&view=rev Log: additional missing feature Modified: llvm/trunk/lib/Target/PowerPC/README.txt Modified: llvm/trunk/lib/Target/PowerPC/README.txt URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/README.txt?rev=46948&r1=46947&r2=46948&view=diff == --- llvm/trunk/lib/Target/PowerPC/README.txt (original) +++ llvm/trunk/lib/Target/PowerPC/README.txt Sun Feb 10 22:16:09 2008 @@ -4,6 +4,7 @@ * gpr0 allocation * implement do-loop -> bdnz transform * Implement __builtin_trap (ISD::TRAP) as 'tw 31, 0, 0' aka 'trap'. +* lmw/stmw pass a la arm load store optimizer for prolog/epilog ===-=== ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46952 - /llvm/trunk/docs/ReleaseNotes.html
Author: lattner Date: Mon Feb 11 01:27:21 2008 New Revision: 46952 URL: http://llvm.org/viewvc/llvm-project?rev=46952&view=rev Log: tweaks from dale. Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=46952&r1=46951&r2=46952&view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Feb 11 01:27:21 2008 @@ -292,8 +292,8 @@ Evan contributed support to the X86 backend to model the mod/ref behavior of the EFLAGS register explicitly in all instructions. This gives more freedom to the scheduler, and is a more explicit way to model the instructions. -Dale contributed support for exception handling on Darwin/x86-64 and -Darwin/PPC. +Dale contributed support for exception handling on Darwin/PPC and he and +Anton got x86-64 working. Evan turned on if-conversion by default for ARM, allowing LLVM to take advantage of its predication features. Bruno added PIC support to the MIPS backend, fixed many bugs and improved ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
[llvm-commits] [llvm] r46951 - /llvm/trunk/docs/ReleaseNotes.html
Author: lattner Date: Mon Feb 11 01:21:08 2008 New Revision: 46951 URL: http://llvm.org/viewvc/llvm-project?rev=46951&view=rev Log: updates from Evan Modified: llvm/trunk/docs/ReleaseNotes.html Modified: llvm/trunk/docs/ReleaseNotes.html URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=46951&r1=46950&r2=46951&view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Feb 11 01:21:08 2008 @@ -97,7 +97,8 @@ LLVM 2.1, llvm-gcc 4.2 was beta). Since LLVM 2.1, the llvm-gcc 4.2 front-end has made leaps and bounds and is now at least as good as 4.0 in virtually every area, and is better in several areas (for example, exception handling -correctness, support for Ada and Fortran). We strongly recommend that you +correctness, support for Ada and Fortran, better ABI compatibility, etc). We +strongly recommend that you migrate from llvm-gcc 4.0 to llvm-gcc 4.2 in this release cycle because LLVM 2.2 is the last release that will support llvm-gcc 4.0: LLVM 2.3 will only support the llvm-gcc 4.2 front-end. @@ -265,7 +266,8 @@ llvm-gcc by default, but can be accessed through 'opt'. Dan Gohman contributed several enhancements to Loop Strength Reduction (LSR) -to make it more aggressive with SSE intrinsics. +to make it more aggressive with SSE intrinsics and when induction variables are +used by non-memory instructions. Evan added support for simple exit value substitution to LSR. ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm] r46922 - /llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
On Feb 10, 2008, at 7:46 PM, Evan Cheng wrote: > What is this fixing? The code as it was was a no-op. This makes it do what the comment says it's supposed to do. > I would expect SelectionDAG to constant > evaluating it to a constant node? > Perhaps. But then why is it here at all then? -bw > On Feb 10, 2008, at 12:10 AM, Bill Wendling wrote: > >> Author: void >> Date: Sun Feb 10 02:10:24 2008 >> New Revision: 46922 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=46922&view=rev >> Log: >> Return "(c1 + c2)" instead of yet another ADD node (which made this a >> no-op). >> >> = >> = >> --- llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp (original) >> +++ llvm/trunk/lib/CodeGen/SelectionDAG/DAGCombiner.cpp Sun Feb 10 >> 02:10:24 2008 >> @@ -923,7 +923,7 @@ >> return N1; >> // fold (add c1, c2) -> c1+c2 >> if (N0C && N1C) >> -return DAG.getNode(ISD::ADD, VT, N0, N1); >> +return DAG.getConstant(N0C->getValue() + N1C->getValue(), VT); >> // canonicalize constant to RHS >> if (N0C && !N1C) >> return DAG.getNode(ISD::ADD, VT, N1, N0); >> >> >> ___ >> 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 mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
Re: [llvm-commits] [llvm-gcc-4.2] r46726 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
On Feb 9, 2008, at 1:24 PM, Duncan Sands wrote: > the current LLVM implementation means that anyone using threading > needs > to not do bitfield accesses, since the compiler generated code could > cause trouble. This is not handled by LLVM, this is handled by FE that is translating source code into LLVM IR. Unless all front-ends enforce this, we can not claim that LLVM guarantees bit-field thread safety (I do think, it is convenient if tools support bit-field thread safety). If you are suggesting to handle this some how inside LLVM itself then I mis- understood your comment. > Are you suggesting that users should roll their own > bitfield code (I'm not saying that this is unreasonable)? No. I'm merely stating current status quo. - Devang ___ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
