On 10/26/06, Steven Bosscher [EMAIL PROTECTED] wrote:
It is not a note, it's a statement. The problem with RTL loop notes
was that they were not statements, but rather markers, e.g. a loop
starts/ends here. The LOOP_HEADER node, on the other hand, is more
like a placeholder for the result of
Hello,
So, the passes that maniuplate loop structure need to know about
LOOP_HEADER and others do not need to worry about LOOP_HEADER.
More acurately, the passes that manipulate the cfg. Right now most of
these passes don't even know they modify the loop structure.
Now, focusing on the
On 10/25/06, Zdenek Dvorak [EMAIL PROTECTED] wrote:
Hello,
So, the passes that maniuplate loop structure need to know about
LOOP_HEADER and others do not need to worry about LOOP_HEADER.
More acurately, the passes that manipulate the cfg. Right now most of
these passes don't even know they
and seeing the reaction of people,
I probably won't use it. The main reason for considering to use
the tree node for me was the possibility to make the number of iterations
of the loop as its operand, so that I would not need to worry about
keeping it alive through dce, copy/constant
On 10/25/06, Andrew Pinski [EMAIL PROTECTED] wrote:
and seeing the reaction of people,
I probably won't use it. The main reason for considering to use
the tree node for me was the possibility to make the number of iterations
of the loop as its operand, so that I would not need to worry
On 10/25/06, Devang Patel [EMAIL PROTECTED] wrote:
One way to achieve this is to mark n_1 (in your example) as
do not dead strip because I know it is used , kind of attribute((used)).
This is what as I understand LOOP_HEADER is used for.
Big difference. New tree vs TREE_USED or
On 10/25/06, Zdenek Dvorak [EMAIL PROTECTED] wrote:
it definitely is not the only way, and seeing the reaction of people,
I probably won't use it. The main reason for considering to use
the tree node for me was the possibility to make the number of iterations
of the loop as its operand, so that
On 10/25/06, Steven Bosscher [EMAIL PROTECTED] wrote:
So you would mark n_1 with TREE_USED, and never let it be removed?
What would happen if e.g. the entire loop turns out to be dead code?
Or if the loop is rewritten (e.g. vectorized) in a way that changes
the number of iterations of the loop?
Hello,
On 10/25/06, Steven Bosscher [EMAIL PROTECTED] wrote:
So you would mark n_1 with TREE_USED, and never let it be removed?
What would happen if e.g. the entire loop turns out to be dead code?
Or if the loop is rewritten (e.g. vectorized) in a way that changes
the number of iterations
On Wed, 2006-10-25 at 13:01 -0700, Devang Patel wrote:
However, various optimizer needs to know about this special tree node.
not really (not any more than they know about other tree codes that are
not interesting for them).
If we take an example of Jump Threading pass then it needs to
On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote:
actually, that will be trivial once jump threading updates loop properly
(I have a patch for that).
I'd like to see that.
I recall poking at having threading update things like loop exit
points and gave up. The problem is you could
Hello,
On Thu, 2006-10-26 at 00:45 +0200, Zdenek Dvorak wrote:
actually, that will be trivial once jump threading updates loop properly
(I have a patch for that).
I'd like to see that.
I recall poking at having threading update things like loop exit
points and gave up. The problem is
12 matches
Mail list logo
