On Jun 18, 2007, at 10:29 PM, Chris Lattner wrote:
>
> Hi Dan,
>
> I'm sorry to be such a pain, but this seems like a step backward.
> We've gone from having an explicit flag in the .td files to having
> another magic table in the .cpp file (somewhat amusing because
> 'duplicable' just made the o
Changes in directory llvm/lib/Transforms/Scalar:
GVNPRE.cpp updated: 1.40 -> 1.41
---
Log message:
Handle constants in phi nodes properly. This fixes
test/Transforms/GVNPRE/2007-06-18-ConstantInPhi.ll
---
Diffs of the changes: (+10 -1)
GVNPRE.cpp | 11 ++-
1 files changed, 10 i
Changes in directory llvm/lib/CodeGen/SelectionDAG:
DAGCombiner.cpp updated: 1.312 -> 1.313
ScheduleDAG.cpp updated: 1.125 -> 1.126
SelectionDAG.cpp updated: 1.407 -> 1.408
---
Log message:
Pass a SelectionDAG into SDNode::dump everywhere it's used, in prepration
for needing the DAG node to pri
Changes in directory llvm/lib/Target/Alpha:
AlphaISelDAGToDAG.cpp updated: 1.69 -> 1.70
---
Log message:
Pass a SelectionDAG into SDNode::dump everywhere it's used, in prepration
for needing the DAG node to print pre-legalize extended value types, and
to get better debug messages with target-sp
Changes in directory llvm/lib/Target/IA64:
IA64ISelDAGToDAG.cpp updated: 1.65 -> 1.66
---
Log message:
Pass a SelectionDAG into SDNode::dump everywhere it's used, in prepration
for needing the DAG node to print pre-legalize extended value types, and
to get better debug messages with target-spec
Changes in directory llvm/include/llvm/Analysis:
ScalarEvolution.h updated: 1.21 -> 1.22
---
Log message:
Rename ScalarEvolution::deleteInstructionFromRecords to
deleteValueFromRecords and loosen the types to all it to accept
Value* instead of just Instruction*, since this is what
ScalarEvoluti
Changes in directory llvm/lib/Analysis:
ScalarEvolution.cpp updated: 1.120 -> 1.121
---
Log message:
Rename ScalarEvolution::deleteInstructionFromRecords to
deleteValueFromRecords and loosen the types to all it to accept
Value* instead of just Instruction*, since this is what
ScalarEvolution us
Changes in directory llvm/lib/Transforms/Scalar:
IndVarSimplify.cpp updated: 1.122 -> 1.123
LoopStrengthReduce.cpp updated: 1.141 -> 1.142
---
Log message:
Rename ScalarEvolution::deleteInstructionFromRecords to
deleteValueFromRecords and loosen the types to all it to accept
Value* instead of j
>> This achieves two things:
>>
>> 1. Just looking at the .td file, you can tell which instructions are
>> candidates for remat.
>> 2. The isRematerializable predicate is faster for instructions that
>> are not remat-able.
>> 3. The isReallyRematerializable only needs to be implemented by
>> target
On Jun 19, 2007, at 8:06 AM, Chris Lattner wrote:
>>> This achieves two things:
>>>
>>> 1. Just looking at the .td file, you can tell which instructions are
>>> candidates for remat.
>>> 2. The isRematerializable predicate is faster for instructions that
>>> are not remat-able.
>>> 3. The isReall
On Jun 19, 2007, at 9:38 AM, Evan Cheng wrote:
>>> If we are really concerned about the speed, then I agree the hybrid
>>> approach is the best. Sorry about the confusion.
>>
>> Speed is something to consider, but I don't think it should override
>> maintainability.
>>
>>> Not to mention I had al
Changes in directory llvm/tools/llvm-ld:
llvm-ld.cpp updated: 1.53 -> 1.54
---
Log message:
Fix pr1448: http://llvm.org/PR1448
---
Diffs of the changes: (+20 -14)
llvm-ld.cpp | 34 --
1 files changed, 20 insertions(+), 14 deletions(-)
Index: llvm/tools/
On Jun 19, 2007, at 9:40 AM, Chris Lattner wrote:
>
> On Jun 19, 2007, at 9:38 AM, Evan Cheng wrote:
>
If we are really concerned about the speed, then I agree the hybrid
approach is the best. Sorry about the confusion.
>>>
>>> Speed is something to consider, but I don't think it should
>> It seems that simple remat works for things that:
>>
>> 1. have no side effects
>> 2. have no register inputs
>>
>> Is there another condition?
>
> Can't think of any.
>
>>
>> If so, simple remat can check #2 today, just by itself looking at the
>> machineinstr. Given that, it comes down to how
On Jun 19, 2007, at 10:31 AM, Chris Lattner wrote:
>>> It seems that simple remat works for things that:
>>>
>>> 1. have no side effects
>>> 2. have no register inputs
>>>
>>> Is there another condition?
>>
>> Can't think of any.
>>
>>>
>>> If so, simple remat can check #2 today, just by itself l
Revision: 128613
Author: clattner
Date: 2007-06-19 10:49:09 -0700 (Tue, 19 Jun 2007)
Log Message:
---
add a new -mllvm -disable-llvm-optzns option, which can be used
to isolate changes in the code made by llvm optimizers from changes
make by GCC FE optimizations.
Modified Paths:
---
>>> I don't see a better way so I guess this will be a targetinstrinfo
>>> bit (true for those with side-effects).
>>
>> Okay, the tricky thing here is instructions that have "conditional
>> side effects". For example, all instructions marked isload/isstore/
>> iscall etc should be considered to h
On Jun 19, 2007, at 10:54 AM, Chris Lattner wrote:
I don't see a better way so I guess this will be a targetinstrinfo
bit (true for those with side-effects).
>>>
>>> Okay, the tricky thing here is instructions that have "conditional
>>> side effects". For example, all instructions mark
Revision: 128616
Author: clattner
Date: 2007-06-19 11:40:06 -0700 (Tue, 19 Jun 2007)
Log Message:
---
Fix a recent regression that broke the logical __builtin_*pd ops.
Modified Paths:
--
apple-local/branches/llvm/gcc/config/i386/llvm-i386.cpp
Modified: apple-local/b
Revision: 128618
Author: clattner
Date: 2007-06-19 13:17:40 -0700 (Tue, 19 Jun 2007)
Log Message:
---
Fix some problems handling function pointers where the default
unary conversions were not applied. Many thanks to
Fariborz Jahanian for writing this patch.
Modified Paths:
--
Changes in directory llvm/lib/Target/ARM:
ARMISelLowering.cpp updated: 1.56 -> 1.57
ARMISelLowering.h updated: 1.16 -> 1.17
ARMInstrInfo.td updated: 1.112 -> 1.113
---
Log message:
Allow predicated immediate ARM to ARM calls.
---
Diffs of the changes: (+14 -1)
ARMISelLowering.cpp |7 +++
On Jun 19, 2007, at 10:31 AM, Chris Lattner wrote:
It seems that simple remat works for things that:
1. have no side effects
2. have no register inputs
Is there another condition?
Can't think of any.
If so, simple remat can check #2 today, just by itself looking at
the
machineinstr.
Changes in directory llvm/lib/CodeGen:
IfConversion.cpp updated: 1.58 -> 1.59
---
Log message:
Avoid if-converting simple block that ends with unconditional branch or
fallthrough unless it branches / falls to the 'false' block. Not profitable,
may end up increasing code size.
---
Diffs of th
Changes in directory llvm-test/MultiSource/Benchmarks/Olden/tsp:
Makefile updated: 1.8 -> 1.9
---
Log message:
Increase test size to something more reasonable.
---
Diffs of the changes: (+1 -1)
Makefile |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: llvm-test/MultiSource
Changes in directory llvm-test/MultiSource/Benchmarks/Olden/power:
power.h updated: 1.5 -> 1.6
---
Log message:
Increase test size to something more reasonable.
---
Diffs of the changes: (+4 -4)
power.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
Index: llvm-test/Mul
Changes in directory llvm-test/MultiSource/Benchmarks/Olden/mst:
Makefile updated: 1.14 -> 1.15
---
Log message:
Increase test size to something more reasonable.
---
Diffs of the changes: (+1 -1)
Makefile |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: llvm-test/MultiSour
Changes in directory llvm-test/MultiSource/Benchmarks/Olden/em3d:
Makefile updated: 1.7 -> 1.8
---
Log message:
Increase test size to something more reasonable.
---
Diffs of the changes: (+3 -1)
Makefile |4 +++-
1 files changed, 3 insertions(+), 1 deletion(-)
Index: llvm-test/MultiSo
>> Okay, the tricky thing here is instructions that have "conditional
>> side effects". For example, all instructions marked isload/isstore/
>> iscall etc should be considered to have side effects (as would
>> anything with implicit definitions), but loads from constant pools
>> and other special
Changes in directory llvm-test/MultiSource/Benchmarks/Olden/bh:
Makefile updated: 1.12 -> 1.13
---
Log message:
Increase test size to something more reasonable.
---
Diffs of the changes: (+6 -0)
Makefile |6 ++
1 files changed, 6 insertions(+)
Index: llvm-test/MultiSource/Benchmar
Changes in directory llvm/include/llvm/Transforms/IPO:
InlinerPass.h added (r1.1)
---
Log message:
Move inliner pass header file.
---
Diffs of the changes: (+64 -0)
InlinerPass.h | 64 ++
1 files changed, 64 insertions(+)
Index: l
Changes in directory llvm/lib/Transforms/IPO:
InlineSimple.cpp updated: 1.85 -> 1.86
Inliner.cpp updated: 1.41 -> 1.42
---
Log message:
Inliner pass header file was moved.
---
Diffs of the changes: (+3 -2)
InlineSimple.cpp |3 ++-
Inliner.cpp |2 +-
2 files changed, 3 insertio
Changes in directory llvm/lib/Transforms/IPO:
Inliner.h (r1.13) removed
---
Log message:
Moved Inliner.h to include/llvm/Transforms/IPO/InlinerPass.h
---
Diffs of the changes: (+0 -0)
0 files changed
___
llvm-commits mailing list
llvm-commits@
Changes in directory llvm/lib/Transforms/Scalar:
GVNPRE.cpp updated: 1.41 -> 1.42
---
Log message:
Make dependsOnInvoke much more specific in what it tests, which in turn make it
much faster to run. This reduces the time to optimize lencondwith a debug
build on PPC from ~450s to ~300s.
---
Changes in directory llvm/lib/Transforms/Scalar:
GVNPRE.cpp updated: 1.42 -> 1.43
---
Log message:
Use a DenseMap instead of an std::map for the value numbering. This reduces
the time to optimize lencod on a PPC Debug build from ~300s to ~140s.
---
Diffs of the changes: (+5 -4)
GVNPRE.cp
Changes in directory llvm/lib/Target/ARM:
ARMISelLowering.cpp updated: 1.57 -> 1.58
---
Log message:
Be more conservative of duplicating blocks.
---
Diffs of the changes: (+1 -1)
ARMISelLowering.cpp |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: llvm/lib/Target/ARM/ARMIS
Changes in directory llvm/lib/Transforms/Scalar:
GVNPRE.cpp updated: 1.43 -> 1.44
---
Log message:
Get rid of an unneeded helper function.
---
Diffs of the changes: (+9 -19)
GVNPRE.cpp | 28 +---
1 files changed, 9 insertions(+), 19 deletions(-)
Index: llvm/lib/
36 matches
Mail list logo
