Hi,
On 10/23/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Hello,
for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
introducing a tree LOOP_HEADER with single argument N (number of
iterations of the loop), that would be present in IL at the beginning of
header of each loop.
Hello,
> On 10/23/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> >Hello,
> >
> >for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> >introducing a tree LOOP_HEADER with single argument N (number of
> >iterations of the loop), that would be present in IL at the beginning of
> >h
Zdenek Dvorak <[EMAIL PROTECTED]> writes:
> for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> introducing a tree LOOP_HEADER with single argument N (number of
> iterations of the loop), that would be present in IL at the beginning of
> header of each loop. I have following mo
> > quite a lot at the moment). To keep the information valid, we need
> > to prevent optimizations from destroying it (e.g., if the number
> > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want
> > DCE to remove it); this is easy to achieve if n_1 would be the
> > argume
Hello,
> >> > quite a lot at the moment). To keep the information valid, we need
> >> > to prevent optimizations from destroying it (e.g., if the number
> >> > is n_1 = n_2 - 1, and this is the last use of n_1, we do not want
> >> > DCE to remove it); this is easy to achieve if n_1 would
> You are proposing to complete the ssa representation such that
> foreach_ssa_uses also iterates over the niter information (a bit like vrp
> modifies the ssa chains with its extra assert information). Wouldn't it
> be possible to not insert this niter information in the representation of
> the
Hello,
> >> You are proposing to complete the ssa representation such that
> >> foreach_ssa_uses also iterates over the niter information (a bit like vrp
> >> modifies the ssa chains with its extra assert information). Wouldn't it
> >> be possible to not insert this niter information in the repre
Hello,
for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
introducing a tree LOOP_HEADER with single argument N (number of
iterations of the loop), that would be present in IL at the beginning of
header of each loop. I have following motivations:
1) One of the goals of the pr
On Wed, 2006-10-25 at 10:31 -0700, Devang Patel wrote:
> > Hello,
> >
> > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> > introducing a tree LOOP_HEADER with single argument N (number of
> > iterations of the loop), that would be present in IL at the beginning of
> > heade
Hello,
> >for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> >introducing a tree LOOP_HEADER with single argument N (number of
> >iterations of the loop), that would be present in IL at the beginning of
> >header of each loop. I have following motivations:
> >
> >1) One of th
Hello,
> > > for project http://gcc.gnu.org/wiki/PreservingLoops, I am considering
> > > introducing a tree LOOP_HEADER with single argument N (number of
> > > iterations of the loop), that would be present in IL at the beginning of
> > > header of each loop. I have following motivations:
> > >
>
> 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 know
about this tree node and update it properly.
So, the p
On 10/25/06, Devang Patel <[EMAIL PROTECTED]> 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
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 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 tha
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 i
Hello,
> 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
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 thre
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 p
On 10/26/06, Jeffrey Law <[EMAIL PROTECTED]> wrote:
> So, the passes that maniuplate loop structure need to know about
> LOOP_HEADER and others do not need to worry about LOOP_HEADER.
Passes which do code motions may need to know about it -- they don't
need to update its contents, but they may ne
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 o
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 k
>
> > 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
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 nee
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 D
On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
You could use TREE_USED, but your suggestion implies that dead code
should be retained in the program,
May be I misunderstood, but it is not dead code. Here is what Zdenek said,
"
...
To keep the information valid, we need
> to preve
On 10/26/06, Devang Patel <[EMAIL PROTECTED]> wrote:
On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> You could use TREE_USED, but your suggestion implies that dead code
> should be retained in the program,
May be I misunderstood, but it is not dead code. Here is what Zdenek said,
"
>
> On 10/25/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
> > You could use TREE_USED, but your suggestion implies that dead code
> > should be retained in the program,
>
> May be I misunderstood, but it is not dead code. Here is what Zdenek said,
The question now has come to the following
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
On 10/25/06, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
Many optimizers would need to be taught to know about TREE_USED (or any
other bit you would use for that). We do not have this type of
restriction for any other ssa names, so this would be brand new
functionality (on the other hand, most opt
31 matches
Mail list logo
