[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=46922view=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=46922r1=46921r2=46922view=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=46923view=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=46923r1=46922r2=46923view=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./li -liGordon rewrote most of the a href=GarbageCollection.htmlAccurate Garbage -Collection/a code in the code generator, making the generated code more -efficient and adding support for the Ocaml garbage collector metadata -format./li +liGordon Henriksen rewrote most of the a href=GarbageCollection.html +Accurate Garbage Collection/a code in the code generator, making the +generated code more efficient and adding support for the Ocaml garbage collector +metadata format./li + +liChristopher 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./li liLLVM now includes a new set of detailed a href=tutorial/index.htmltutorials/a, which explain how to implement a @@ -151,6 +156,44 @@ !--=-- div class=doc_subsection +a name=coreimprovementsLLVM Core Improvements/a +/div + +div class=doc_text +pNew features include: +/p + +ul +liGordon contributed support for C and Ocaml Bindings for the basic LLVM IR +construction routines as well as several other auxiliary APIs./li + +liAnton 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./li + +liDevang added LLVMFoldingBuilder, a version of LLVMBuilder that implicitly +simplifies the code as it is constructed./li + +liTed 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./li + +liDuncan 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./li + +liDuncan 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./li + +liDan Gohman added support for vector sin, cos, and pow intrinsics./li + +/ul + +/div + +!--=-- +div class=doc_subsection a name=codegenCode Generator Improvements/a /div @@ -211,15 +254,15 @@ div class=doc_text -pIn addition to a huge array of bug fixes and minor performance tweaks, LLVM -2.2 supports a few major enhancements:/p +pIn addition to a huge array of bug fixes and minor performance tweaks, the +LLVM 2.2 optimizers support a few major enhancements:/p ul liDaniel 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./li +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'./li liDan Gohman contributed several enhancements to Loop Strength Reduction (LSR) to make it more aggressive with SSE intrinsics./li @@ -240,48 +283,23 @@ /div div class=doc_text -pNew features include: +pNew target-specific features include: /p ul -liEvan X86 now models EFLAGS in instructions./li -liEvan: If conversion on by default for ARM./li -liBruno: MIPS PIC support./li -liArnold Schwaighofer: X86 tail call support./li -liDale darwin/x86-64 and darwin/ppc eh/li -liEvan: darwin/x86 debug info, improvements at -O0?/li -/ul - -/div - -!--=-- -div class=doc_subsection -a name=coreimprovementsLLVM Core Improvements/a -/div - -div class=doc_text -pNew features include: -/p - -ul -liDevang added LLVMFoldingBuilder./li -liDan added support for vector sin, cos, and pow intrinsics./li -liTed 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./li -liDuncan fixed TargetData to distinguish between the
[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=46924view=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=46924r1=46923r2=46924view=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.htmltutorials/a, which explain how to implement a language with LLVM and shows how to use several important APIs./li +/ul + /div !--=-- @@ -697,7 +699,7 @@ a href=http://jigsaw.w3.org/css-validator/check/referer;img src=http://jigsaw.w3.org/css-validator/images/vcss; alt=Valid CSS!/a a href=http://validator.w3.org/check/referer;img - src=http://www.w3.org/Icons/valid-html401; alt=Valid HTML 4.01! //a + src=http://www.w3.org/Icons/valid-html401; alt=Valid HTML 4.01!/a a href=http://llvm.org/;LLVM Compiler Infrastructure/abr Last modified: $Date$ ___ 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=46927view=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=46927r1=46926r2=46927view=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=46928view=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=46928r1=46927r2=46928view=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 bLLVM 2.2 is the last release that will support llvm-gcc 4.0/b: LLVM 2.3 will only support the llvm-gcc 4.2 front-end./p @@ -126,11 +126,11 @@ liScott Michel contributed an SPU backend, which generates code for the vector coprocessors on the Cell processor. (Status?)/li -lillvm-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 a -href=http://llvm.org/PR1971;not support EQUIVALENCE yet/a./li +liAnton 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 a href=#knownproblemslist of known problems/a. +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). liDale 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./li liAnton 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./li liDevang 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./li -liDuncan moved parameter attributes off of FunctionType and onto functions +liReid 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./li @@ -211,7 +211,7 @@ and backward dominator computation./li liDan 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./li liEvan extended the DAG scheduler to model physical register dependencies @@ -300,6 +300,7 @@ details?)./li liEvan contributed several enhancements to Darwin/x86 debug information, and improvements at -O0 (details?)./li +liDuncan added x86-64 support for trampolines (pointers to nested functions)./li /ul /div @@ -528,6 +529,7 @@ lia href=http://llvm.org/PR1658;The C backend violates the ABI of common C++ programs/a, preventing intermixing between C++ compiled by the CBE and C++ code compiled with LLC or native compilers./li +liThe C backend does not support all exception handling constructs./li /ul /div @@ -538,6 +540,52 @@ a name=c-feKnown problems with the C front-end/a /div +!-- === -- +div class=doc_subsection + a name=ada-feKnown problems with the Ada front-end/a +/div + +div class=doc_text +The llvm-gcc 4.2 Ada compiler works fairly well, however this is not a mature +technology and problems should be expected. +ul +liThe 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 a href=http://llvm.org/PR2006;also fails to build on x86-64/a +which does support trampolines./li +liThe Ada front-end a href=http://llvm.org/PR2007;fails to bootstrap/a. +Workaround: configure with --disable-bootstrap./li +liThe c380004 and a href=http://llvm.org/PR2010;c393010/a ACATS tests +fail (c380004 also fails with gcc-4.2 mainline)./li +liMany gcc specific Ada tests continue to crash the compiler./li +liThe -E binder
[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=46929view=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=46929r1=46928r2=46929view=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 a href=#knownproblemslist of known problems/a. 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)./li liDale 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 @@ div class=www_sectiontitleWant to learn more?/div -pIf you'd like to learn more about LLVM, take a look at a -href=pubs/2004-09-22-LCPCLLVMTutorial.htmlLLVM Tutorial/a and the extensive +pIf you'd like to learn more about LLVM, take a look at the a +href=docs/tutorial/LLVM Tutorials/a and the extensive a href=docs/documentation/a for LLVM. In particular, all of the tools distributed with LLVM are described in the a href=docs/CommandGuide/LLVM Command Guide/a. 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=46931view=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=46931r1=46930r2=46931view=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 : SS4AIopc, MRMSrcReg, (outs VR128:$dst),
(ins VR128:$src1, VR128:$src2, i32i8imm:$src3),
!strconcat(OpcodeStr,
- \t{$$src3, src2, $dst|$dst, $src2, $src3}),
+ \t{$src3, $src2, $dst|$dst, $src2, $src3}),
[(set VR128:$dst,
(IntId128 VR128:$src1, VR128:$src2, imm:$src3))],
OpSize {
@@ -3232,7 +3232,7 @@
def rmi : SS4AIopc, MRMSrcMem, (outs VR128:$dst),
(ins VR128:$src1, i128mem:$src2, i32i8imm:$src3),
!strconcat(OpcodeStr,
- \t{$$src3, src2, $dst|$dst, $src2, $src3}),
+ \t{$src3, $src2, $dst|$dst, $src2, $src3}),
[(set VR128:$dst,
(IntId128 VR128:$src1,
(bitconvert (memopv16i8 addr:$src2)), imm:$src3))],
@@ -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_intbits8 opc, string OpcodeStr, Intrinsic IntId
{
+def rr0 : SS48Iopc, MRMSrcReg, (outs VR128:$dst),
+(ins VR128:$src1, VR128:$src2),
+!strconcat(OpcodeStr,
+ \t{%xmm0, $src2, $dst|$dst, $src2, %xmm0}),
+[(set VR128:$dst, (IntId VR128:$src1, VR128:$src2,
XMM0))],
+OpSize;
+
+def rm0 : SS48Iopc, MRMSrcMem, (outs VR128:$dst),
+(ins VR128:$src1, i128mem:$src2),
+!strconcat(OpcodeStr,
+ \t{%xmm0, $src2, $dst|$dst, $src2, %xmm0}),
+[(set VR128:$dst,
+ (IntId VR128:$src1,
+ (bitconvert (memopv16i8 addr:$src2)), XMM0))], OpSize;
+ }
+}
+
+defm BLENDVPD : SS41I_ternary_int0x15, blendvpd,
int_x86_sse41_blendvpd;
+defm BLENDVPS : SS41I_ternary_int0x14, blendvps,
int_x86_sse41_blendvps;
+defm PBLENDVB : SS41I_ternary_int0x10, pblendvb,
int_x86_sse41_pblendvb;
+
+
multiclass SS41I_binop_rm_int8bits8 opc, string OpcodeStr, Intrinsic IntId
{
def rr : SS48Iopc, MRMSrcReg, (outs VR128:$dst), (ins VR128:$src),
!strconcat(OpcodeStr, \t{$src, $dst|$dst, $src}),
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://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: next tutorial section 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=46930view=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=46932view=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=46932r1=46931r2=46932view=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_castVectorType(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=46933view=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: next tutorial section 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=46933r1=46932r2=46933view=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 @@ div class=doc_text -pFor 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:/p +pFor 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:/p div class=doc_code pre @@ -86,7 +86,7 @@ /pre /div -pThe 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 codemakeLLVMModule()/code function to do the real work of creating the module. Donât worry, weâll be looking at that one next!/p +pThe 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 codemakeLLVMModule()/code function to do the real work of creating the module. Donât worry, weâll be looking at that one next!/p pThe 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./p @@ -106,7 +106,7 @@ div class=doc_code pre - Constant* c = mod-getOrInsertFunction(mul_add, + Constant* c = mod-gt;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 = castlt;Functiongt;(c); - mul_add-setCallingConv(CallingConv::C); + mul_add-gt;setCallingConv(CallingConv::C); /pre /div -pWe construct our codeFunction/code by calling codegetOrInsertFunction()/code on our module, passing in the name, return type, and argument types of the function. In the case of our codemul_add/code function, that means one 32-bit integer for the return value, and three 32-bit integers for the arguments./p +pWe construct our codeFunction/code by calling codegetOrInsertFunction()/code on our module, passing in the name, return type, and argument types of the function. In the case of our codemul_add/code function, that means one 32-bit integer for the return value and three 32-bit integers for the arguments./p -pYou'll notice that codegetOrInsertFunction/code doesn't actually return a codeFunction*/code. This is because, if the function already existed, but with a different prototype, codegetOrInsertFunction/code will return a cast of the existing function to the desired prototype. Since we know that there's not already a codemul_add/code function, we can safely just cast codec/code to a codeFunction*/code. +pYou'll notice that codegetOrInsertFunction()/code doesn't actually return a codeFunction*/code. This is because codegetOrInsertFunction()/code will return a cast of the existing function if the function already
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=46827view=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=46585r1=46584r2=46585view=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 ManagedStaticPseudoSourceValue[5] 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=46827r1=46826r2=46827view=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=46934view=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=46934r1=46933r2=46934view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Sun Feb 10 14:08:16 2008 @@ -138,7 +138,7 @@ liGordon Henriksen rewrote most of the a href=GarbageCollection.html Accurate Garbage Collection/a 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./li liChristopher Lamb contributed support for multiple address spaces in LLVM @@ -164,7 +164,7 @@ /p ul -liGordon contributed support for C and Ocaml Bindings for the basic LLVM IR +liGordon contributed support for C and OCaml Bindings for the basic LLVM IR construction routines as well as several other auxiliary APIs./li liAnton 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./li liDale contributed support for exception handling on Darwin/x86-64 and -Darwin/ppc./li +Darwin/PPC./li liEvan turned on if-conversion by default for ARM, allowing LLVM to take advantage of its predication features./li liBruno 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=46827view=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 isaMemOperandSDNode(...)
+--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_castGlobalValue*(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_castconst FrameIndexSDNode(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::vectorstd::pairstd::string, std::string OrigChains;
std::setstd::string Duplicates;
+ /// LSI - Load/Store information.
+ /// Save
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)
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=46916view=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=46916r1=46915r2=46916view=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=46922view=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=46922r1=46921r2=46922view=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] 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=46952view=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=46952r1=46951r2=46952view=diff == --- llvm/trunk/docs/ReleaseNotes.html (original) +++ llvm/trunk/docs/ReleaseNotes.html Mon Feb 11 01:27:21 2008 @@ -292,8 +292,8 @@ liEvan 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./li -liDale contributed support for exception handling on Darwin/x86-64 and -Darwin/PPC./li +liDale contributed support for exception handling on Darwin/PPC and he and +Anton got x86-64 working./li liEvan turned on if-conversion by default for ARM, allowing LLVM to take advantage of its predication features./li liBruno 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-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
