On Dec 11, 2007, at 10:45 PM, Chris Lattner wrote:
@foo = internal global i32 0 addrspace(1)
@foo = weak global i32 0 addrspace(1)
@foo = linkonce global i32 0 addrspace(1)
@foo = appending global i32 0 addrspace(1)
@foo = dllexport global i32 0 addrspace(1)
I prefer that too, but I don't see
On Dec 12, 2007, at 12:16 AM, Christopher Lamb wrote:
>>>
>>>
>>> They don't.
>>
>> Ok. It would still be nicer to get to:
> @foo = dllexport global i32 addrspace(1) 0
>>
>> :)
>
> Yes. Bison ate its own head when I tried to do this though. Also
> there are nasty side affects of allowing a
Author: evancheng
Date: Wed Dec 12 02:05:40 2007
New Revision: 44931
URL: http://llvm.org/viewvc/llvm-project?rev=44931&view=rev
Log:
Test -optimize-ext-uses as x86 llcbeta.
Modified:
test-suite/trunk/Makefile.programs
Modified: test-suite/trunk/Makefile.programs
URL:
http://llvm.org/viewvc
Author: clamb
Date: Wed Dec 12 02:44:39 2007
New Revision: 44933
URL: http://llvm.org/viewvc/llvm-project?rev=44933&view=rev
Log:
Implement part of review feedback for address spaces.
Modified:
llvm/trunk/docs/LangRef.html
llvm/trunk/include/llvm/Bitcode/LLVMBitCodes.h
llvm/trunk/lib/
On Dec 11, 2007, at 4:12 PM, Chris Lattner wrote:
> Also, should it be possible to place a function in an address space?
I think probably not...
> Does the embedded C spec allow this?
"A function type shall not be qualified by an address-space qualifier."
I don't think this precludes the comp
Hi Owen,
I know it's work in progress. But could you add some comments? I would
like to follow the code. :-)
Thx,
Evan
On Dec 11, 2007, at 12:12 PM, Owen Anderson <[EMAIL PROTECTED]> wrote:
> Author: resistor
> Date: Tue Dec 11 14:12:11 2007
> New Revision: 44877
>
> URL: http://llvm.org/vie
On Dec 11, 2007, at 11:40 AM, Bill Wendling <[EMAIL PROTECTED]> wrote:
> Author: void
> Date: Tue Dec 11 13:40:06 2007
> New Revision: 44874
>
> URL: http://llvm.org/viewvc/llvm-project?rev=44874&view=rev
> Log:
> Blark! How in the world did this work without this?!
Is this just cosmetic change
On Dec 11, 2007, at 4:12 PM, Chris Lattner wrote:
Making the address space default to zero is convenient, but
dangerous. This means that xforms that play with pointers need to be
very careful to propagate this info in some cases. Do you think this
is the best way to go? Do many clients of Po
Author: baldrick
Date: Wed Dec 12 09:11:38 2007
New Revision: 44935
URL: http://llvm.org/viewvc/llvm-project?rev=44935&view=rev
Log:
Turn off ipa-pure-const, the pass that deduces
whether functions are pure and constant: it makes
wrong deductions because it doesn't know about
LLVM's array_ref hack
Author: wmat
Date: Wed Dec 12 09:21:32 2007
New Revision: 44936
URL: http://llvm.org/viewvc/llvm-project?rev=44936&view=rev
Log:
1. "Upgrage" comments.
2. Using zero-extended value of Scale and unsigned division is safe provided
that Scale doesn't have the sign bit set.
Previously these 2 in
Author: baldrick
Date: Wed Dec 12 10:01:40 2007
New Revision: 44937
URL: http://llvm.org/viewvc/llvm-project?rev=44937&view=rev
Log:
Revert r44626, which turned off the use of readonly
and readnone for functions with bodies because it
broke llvm-gcc-4.2 bootstrap. It turns out that,
because of LL
On Dec 12, 2007, at 12:39 AM, Christopher Lamb wrote:
>
> On Dec 11, 2007, at 4:12 PM, Chris Lattner wrote:
>
>> Also, should it be possible to place a function in an address space?
>
> I think probably not...
>
>> Does the embedded C spec allow this?
>
> "A function type shall not be qualified b
On Dec 12, 2007, at 1:38 AM, Evan Cheng wrote:
>
>
> On Dec 11, 2007, at 11:40 AM, Bill Wendling <[EMAIL PROTECTED]>
> wrote:
>
>> Author: void
>> Date: Tue Dec 11 13:40:06 2007
>> New Revision: 44874
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=44874&view=rev
>> Log:
>> Blark! How in the
Author: asl
Date: Wed Dec 12 13:08:44 2007
New Revision: 44952
URL: http://llvm.org/viewvc/llvm-project?rev=44952&view=rev
Log:
Use vector for child storage instead of map. This will also make
our life during future GraphTraits'ing slightly easier.
Modified:
llvm/trunk/include/llvm/ADT/Trie.h
On Dec 12, 2007, at 1:32 AM, Christopher Lamb wrote:
>
> On Dec 11, 2007, at 4:12 PM, Chris Lattner wrote:
>
>> Making the address space default to zero is convenient, but
>> dangerous. This means that xforms that play with pointers need to be
>> very careful to propagate this info in some cases
> URL: http://llvm.org/viewvc/llvm-project?rev=44933&view=rev
> Log:
> Implement part of review feedback for address spaces.
Also, please update the alloca/malloc descriptions to say that the
pointer has to be in the default address space, and plz make the
verifier check this.
Thanks!
-Chris
On Dec 12, 2007 1:38 AM, Evan Cheng <[EMAIL PROTECTED]> wrote:
>
>
> On Dec 11, 2007, at 11:40 AM, Bill Wendling <[EMAIL PROTECTED]> wrote:
>
> > Author: void
> > Date: Tue Dec 11 13:40:06 2007
> > New Revision: 44874
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=44874&view=rev
> > Log:
> >
On Dec 12, 2007, at 11:12 AM, Bill Wendling wrote:
>
>> One thing that is some what annoying to me is if LICM is after live
>> variables then it won't need to compute vreg def info or liveness
>> info. I wonder if it is possible to move the pass after live
>> variables?
>>
> I'm sure I could mov
On Dec 12, 2007, at 9:59 AM, Chris Lattner wrote:
>
> On Dec 12, 2007, at 1:38 AM, Evan Cheng wrote:
>
>>
>>
>> On Dec 11, 2007, at 11:40 AM, Bill Wendling <[EMAIL PROTECTED]>
>> wrote:
>>
>>> Author: void
>>> Date: Tue Dec 11 13:40:06 2007
>>> New Revision: 44874
>>>
>>> URL: http://llvm.org/vie
vreg definition info is trivial but there is no reverse link from
vreg to defining MachineInstruction. That's what
MachineLICM::MapVirtualRegisterDefs() is constructing.
Evan
On Dec 12, 2007, at 11:59 AM, Evan Cheng wrote:
>
> On Dec 12, 2007, at 9:59 AM, Chris Lattner wrote:
>
>>
>> On Dec
On Dec 12, 2007 11:32 AM, Evan Cheng <[EMAIL PROTECTED]> wrote:
> On Dec 12, 2007, at 11:12 AM, Bill Wendling wrote:
> > I'm sure I could move it, but as Chris asked, isn't it trivial to get
> > this information anyway? Also, I'm kind of hesitant to put so much
> > effort into compile-time performa
Author: djg
Date: Wed Dec 12 16:21:26 2007
New Revision: 44954
URL: http://llvm.org/viewvc/llvm-project?rev=44954&view=rev
Log:
Allow vector integer constants to be created with
SelectionDAG::getConstant, in the same way as vector floating-point
constants. This allows the legalize expansion code f
Author: djg
Date: Wed Dec 12 16:25:09 2007
New Revision: 44955
URL: http://llvm.org/viewvc/llvm-project?rev=44955&view=rev
Log:
Remove a forward-declaration for a non-existant class.
Modified:
llvm/trunk/include/llvm/Target/TargetInstrInfo.h
Modified: llvm/trunk/include/llvm/Target/TargetIns
On Dec 12, 2007, at 2:02 PM, Bill Wendling wrote:
> On Dec 12, 2007 11:32 AM, Evan Cheng <[EMAIL PROTECTED]> wrote:
>> On Dec 12, 2007, at 11:12 AM, Bill Wendling wrote:
>>> I'm sure I could move it, but as Chris asked, isn't it trivial to
>>> get
>>> this information anyway? Also, I'm kind of
Hi Devang,
> Do not emit pending decls twice.
...
> --- llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp (original)
> +++ llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp Tue Dec 11 17:17:57 2007
> @@ -897,7 +897,8 @@
>}
>
>if (TheDebugInfo) TheDebugInfo->EmitGlobalVariable(GV, decl);
> -
> +
> + TR
On Dec 12, 2007, at 2:21 PM, Dan Gohman wrote:
>
> Modified: llvm/trunk/lib/Target/X86/X86ISelLowering.cpp
> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/
> X86ISelLowering.cpp?rev=44954&r1=44953&r2=44954&view=diff
>
> ===
Author: dpatel
Date: Wed Dec 12 16:55:05 2007
New Revision: 44958
URL: http://llvm.org/viewvc/llvm-project?rev=44958&view=rev
Log:
set TREE_ASM_WRITTEN bit even if node is not processed due to previous errors.
Modified:
llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp
Modified: llvm-gcc-4.2/trunk/gcc
On Dec 12, 2007 2:55 PM, Devang Patel <[EMAIL PROTECTED]> wrote:
> +return; // Do not process broken code.
Where's your sense of adventure?! ;-)
-bw
___
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/l
Author: baldrick
Date: Wed Dec 12 17:03:45 2007
New Revision: 44959
URL: http://llvm.org/viewvc/llvm-project?rev=44959&view=rev
Log:
Remove host endianness info from TargetData and
put it in a new header System/Host.h instead.
Instead of getting the endianness from configure,
calculate it directly
On Dec 12, 2007 3:03 PM, Duncan Sands <[EMAIL PROTECTED]> wrote:
> Remove host endianness info from TargetData and
> put it in a new header System/Host.h instead.
> Instead of getting the endianness from configure,
> calculate it directly.
>
Way to obviate my last post. ;-)
-bw
___
Author: evancheng
Date: Wed Dec 12 17:12:09 2007
New Revision: 44960
URL: http://llvm.org/viewvc/llvm-project?rev=44960&view=rev
Log:
Implicit def instructions, e.g. X86::IMPLICIT_DEF_GR32, are always
re-materializable and they should not be spilled.
Added:
llvm/trunk/test/CodeGen/X86/2007-1
Author: evancheng
Date: Wed Dec 12 17:15:59 2007
New Revision: 44961
URL: http://llvm.org/viewvc/llvm-project?rev=44961&view=rev
Log:
Cosmetic change.
Modified:
llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h
Modified: llvm/trunk/include/llvm/CodeGen/SelectionDAGNodes.h
URL:
http://llvm
Author: lattner
Date: Wed Dec 12 18:04:46 2007
New Revision: 44965
URL: http://llvm.org/viewvc/llvm-project?rev=44965&view=rev
Log:
Fix for edge profiling, patch by 'Marc' for PR1857
Modified:
llvm/trunk/lib/Transforms/Instrumentation/EdgeProfiling.cpp
Modified: llvm/trunk/lib/Transforms/Ins
Author: evancheng
Date: Wed Dec 12 18:42:35 2007
New Revision: 44969
URL: http://llvm.org/viewvc/llvm-project?rev=44969&view=rev
Log:
Oops. Forgot these.
Modified:
llvm/trunk/utils/TableGen/CodeGenInstruction.h
llvm/trunk/utils/TableGen/CodeGenTarget.cpp
llvm/trunk/utils/TableGen/Inst
Author: evancheng
Date: Wed Dec 12 18:43:27 2007
New Revision: 44970
URL: http://llvm.org/viewvc/llvm-project?rev=44970&view=rev
Log:
Fold some and + shift in x86 addressing mode.
Added:
llvm/trunk/test/CodeGen/X86/fold-and-shift.ll
Modified:
llvm/trunk/lib/Target/X86/X86ISelDAGToDAG.cpp
Author: evancheng
Date: Wed Dec 12 18:51:41 2007
New Revision: 44971
URL: http://llvm.org/viewvc/llvm-project?rev=44971&view=rev
Log:
Doh.
Modified:
test-suite/trunk/Makefile.programs
Modified: test-suite/trunk/Makefile.programs
URL:
http://llvm.org/viewvc/llvm-project/test-suite/trunk/Make
On Dec 12, 2007, at 3:12 PM, Evan Cheng wrote:
>isLoad = false;
> - if (tii_->isTriviallyReMaterializable(MI)) {
> -isLoad = MI->getInstrDescriptor()->Flags & M_LOAD_FLAG;
> + const TargetInstrDescriptor *TID = MI->getInstrDescriptor();
> + if ((TID->Flags & M_IMPLICIT_DEF_FLAG) ||
> +
Author: sampo
Date: Wed Dec 12 19:18:52 2007
New Revision: 44973
URL: http://llvm.org/viewvc/llvm-project?rev=44973&view=rev
Log:
Do not build CBackend and MSIL regardless of configured targets
Modified:
llvm/trunk/configure
Modified: llvm/trunk/configure
URL:
http://llvm.org/viewvc/llvm-pr
On Dec 12, 2007, at 5:07 PM, Chris Lattner wrote:
> On Dec 12, 2007, at 3:12 PM, Evan Cheng wrote:
>>isLoad = false;
>> - if (tii_->isTriviallyReMaterializable(MI)) {
>> -isLoad = MI->getInstrDescriptor()->Flags & M_LOAD_FLAG;
>> + const TargetInstrDescriptor *TID = MI->getInstrDescript
On Dec 12, 2007, at 5:37 PM, Evan Cheng wrote:
>
> On Dec 12, 2007, at 5:07 PM, Chris Lattner wrote:
>
>> On Dec 12, 2007, at 3:12 PM, Evan Cheng wrote:
>>>isLoad = false;
>>> - if (tii_->isTriviallyReMaterializable(MI)) {
>>> -isLoad = MI->getInstrDescriptor()->Flags & M_LOAD_FLAG;
>>>
>> At one point were discussed eliminating
>> TII::isTriviallyReMaterializable. The argument is that target
>> implementations shouldn't have to know about algorithms, they should
>> just describe properties of the target, and the algorithm should
>> figure out if it can make the xform from that i
>>> At one point were discussed eliminating
>>> TII::isTriviallyReMaterializable. The argument is that target
>>> implementations shouldn't have to know about algorithms, they should
>>> just describe properties of the target, and the algorithm should
>>> figure out if it can make the xform from t
Author: johannes
Date: Wed Dec 12 19:51:55 2007
New Revision: 44975
URL: http://llvm.org/viewvc/llvm-project?rev=44975&view=rev
Log:
Use Unwind_Resume_or_Rethrow instead of Unwind_Resume
for Darwin stack unwind.
Modified:
llvm-gcc-4.2/trunk/gcc/config/darwin.h
llvm-gcc-4.2/trunk/gcc/excep
Did you forget to check in configure.ac for this change?
-Tanya
On Dec 12, 2007, at 5:18 PM, Nate Begeman wrote:
> Author: sampo
> Date: Wed Dec 12 19:18:52 2007
> New Revision: 44973
>
> URL: http://llvm.org/viewvc/llvm-project?rev=44973&view=rev
> Log:
> Do not build CBackend and MSIL regardle
On Dec 12, 2007, at 5:51 PM, Chris Lattner wrote:
At one point were discussed eliminating
TII::isTriviallyReMaterializable. The argument is that target
implementations shouldn't have to know about algorithms, they
should
just describe properties of the target, and the
Author: sheng
Date: Wed Dec 12 20:03:57 2007
New Revision: 44977
URL: http://llvm.org/viewvc/llvm-project?rev=44977&view=rev
Log:
Remove this testcase as it will always fail on
platform like Darwin.
Removed:
llvm/trunk/test/ExecutionEngine/2007-12-11-APIntExFuncCall.ll
Removed: llvm/trunk/te
Author: sampo
Date: Wed Dec 12 20:17:17 2007
New Revision: 44979
URL: http://llvm.org/viewvc/llvm-project?rev=44979&view=rev
Log:
Add install-libs target which only installs libraries, not tools
Modified:
llvm/trunk/Makefile
Modified: llvm/trunk/Makefile
URL:
http://llvm.org/viewvc/llvm-pro
Author: sampo
Date: Wed Dec 12 20:24:45 2007
New Revision: 44980
URL: http://llvm.org/viewvc/llvm-project?rev=44980&view=rev
Log:
Apply CBE/MSIL patch to autoconf
Modified:
llvm/trunk/autoconf/configure.ac
Modified: llvm/trunk/autoconf/configure.ac
URL:
http://llvm.org/viewvc/llvm-project/l
Author: evancheng
Date: Wed Dec 12 21:32:53 2007
New Revision: 44981
URL: http://llvm.org/viewvc/llvm-project?rev=44981&view=rev
Log:
Be extra careful with extension use optimation. Now turned on by default.
Modified:
llvm/trunk/lib/Transforms/Scalar/CodeGenPrepare.cpp
llvm/trunk/test/Cod
>>> X86::isReallyTriviallyReMaterializable() is:
>>> ...
>>> case X86::MMX_MOVD64rm:
>>> case X86::MMX_MOVQ64rm:
>>> // Loads from constant pools are trivially rematerializable.
>>> return MI->getOperand(1).isRegister() && MI->getOperand
>>> (2).isImmediate() &&
>>>MI->getOp
Evan Cheng wrote:
> @@ -929,6 +929,10 @@
>if (Src->hasOneUse())
> return false;
>
> + // Only do this xform is truncating is free.
Should read ...xform if* truncating...
> + if (!TLI->isTruncateFree(I->getType(), Src->getType()))
> +return false;
> +
>// Only safe to perform
On Dec 12, 2007, at 7:32 PM, Evan Cheng wrote:
> Author: evancheng
> Date: Wed Dec 12 21:32:53 2007
> New Revision: 44981
>
> URL: http://llvm.org/viewvc/llvm-project?rev=44981&view=rev
> Log:
> Be extra careful with extension use optimation. Now turned on by
> default.
FYI, on your testcase wi
Author: resistor
Date: Wed Dec 12 23:43:37 2007
New Revision: 44986
URL: http://llvm.org/viewvc/llvm-project?rev=44986&view=rev
Log:
Remove ugly and horrible code. It's not necessary for correctness, and can be
added back later if it causes code quality issues.
Modified:
llvm/trunk/lib/Code
Author: resistor
Date: Wed Dec 12 23:53:03 2007
New Revision: 44987
URL: http://llvm.org/viewvc/llvm-project?rev=44987&view=rev
Log:
Add register pairs to the list to check for local interferences.
Modified:
llvm/trunk/lib/CodeGen/StrongPHIElimination.cpp
Modified: llvm/trunk/lib/CodeGen/Str
On Dec 12, 2007, at 8:40 PM, Chris Lattner wrote:
> On Dec 12, 2007, at 7:32 PM, Evan Cheng wrote:
>
>> Author: evancheng
>> Date: Wed Dec 12 21:32:53 2007
>> New Revision: 44981
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=44981&view=rev
>> Log:
>> Be extra careful with extension use optim
Author: evancheng
Date: Thu Dec 13 01:50:36 2007
New Revision: 44997
URL: http://llvm.org/viewvc/llvm-project?rev=44997&view=rev
Log:
Fix typo.
Modified:
llvm/trunk/lib/Transforms/Scalar/CodeGenPrepare.cpp
Modified: llvm/trunk/lib/Transforms/Scalar/CodeGenPrepare.cpp
URL:
http://llvm.org/vi
Fixed. Thx.
Evan
On Dec 12, 2007, at 8:26 PM, Nick Lewycky wrote:
> Evan Cheng wrote:
>> @@ -929,6 +929,10 @@
>>if (Src->hasOneUse())
>> return false;
>>
>> + // Only do this xform is truncating is free.
>
> Should read ...xform if* truncating...
>
>> + if (!TLI->isTruncateFree(I->getT
57 matches
Mail list logo
