Hi,
On Tue, 21 May 2019, Richard Biener wrote:
> > Index: gcc/tree-ssa-dce.c
> > ===
> > --- gcc/tree-ssa-dce.c (revision 271415)
> > +++ gcc/tree-ssa-dce.c (working copy)
> > @@ -417,7 +417,7 @@ find_obviously_necessary_stmts (boo
On Tue, May 21, 2019 at 12:12 PM Richard Biener
wrote:
>
> On Mon, May 20, 2019 at 4:51 PM Feng Xue OS
> wrote:
> >
> > > I don't see how it is safe in a late pass when it is not safe in an
> >
> > > earlier one. Optimization is imperfect - we could fail to remove
> > > an "obvious" never taken
On Mon, May 20, 2019 at 4:51 PM Feng Xue OS wrote:
>
> > I don't see how it is safe in a late pass when it is not safe in an
>
> > earlier one. Optimization is imperfect - we could fail to remove
> > an "obvious" never taken exit and still have a loop that appears to be
> > finite according to ou
On Mon, 20 May 2019, Michael Matz wrote:
On Mon, 20 May 2019, Richard Biener wrote:
The C++ standard says that do{}while(1) is __builtin_unreachable(), we
don't have to preserve it. There is no mention of anything like a
"nontrivial exit condition". Other languages may have a different
opinion
> I don't see how it is safe in a late pass when it is not safe in an
> earlier one. Optimization is imperfect - we could fail to remove
> an "obvious" never taken exit and still have a loop that appears to be
> finite according to our definition.
Yes. it is. This is somewhat similar to strict-a
Hi,
On Mon, 20 May 2019, Richard Biener wrote:
> > The C++ standard says that do{}while(1) is __builtin_unreachable(), we
> > don't have to preserve it. There is no mention of anything like a
> > "nontrivial exit condition". Other languages may have a different
> > opinion though, so it would
On Mon, May 20, 2019 at 4:00 PM Feng Xue OS wrote:
>
> >> I specialized a CD-DCE pass, named CD-DCE2, and only in this pass, loop
> >> removal based on assumed finteness is performed. Please check the patch.
>
>
> > Oh, but why not generally do this?
>
> It is nature that real finiteness of loop
>> I specialized a CD-DCE pass, named CD-DCE2, and only in this pass, loop
>> removal based on assumed finteness is performed. Please check the patch.
> Oh, but why not generally do this?
It is nature that real finiteness of loop should override assumed one. As you
said, CD-DCE could be invocat
On Mon, May 20, 2019 at 3:04 PM Marc Glisse wrote:
>
> On Mon, 20 May 2019, Richard Biener wrote:
>
> > On Sat, May 18, 2019 at 4:00 PM Marc Glisse wrote:
> >>
> >> (@Feng Xue, it is better to include testcases in your patches)
> >>
> I'm not a big fan of this patch. I'd rather be looking a
On Mon, 20 May 2019, Richard Biener wrote:
On Sat, May 18, 2019 at 4:00 PM Marc Glisse wrote:
(@Feng Xue, it is better to include testcases in your patches)
I'm not a big fan of this patch. I'd rather be looking at either
improving our analysis
Better analysis cannot hurt.
or adding at
On Mon, May 20, 2019 at 11:48 AM Feng Xue OS
wrote:
>
> >> Now finiteness assertion is only used in a very late CD-DCE, which is
> >> located after all loop optimizations are done. And we can even place it as
> >> late as just before RTL-expansion. This might be safe enough to let hidden
> >> i
>> Now finiteness assertion is only used in a very late CD-DCE, which is
>> located after all loop optimizations are done. And we can even place it as
>> late as just before RTL-expansion. This might be safe enough to let hidden
>> infinite loops exposed.
> Is that so? The early pipeline conta
On Mon, May 20, 2019 at 10:27 AM Feng Xue OS
wrote:
>
>
> >>
> >> IIUC that was slightly different: "This option tells the loop optimizer to
> >> assume that loop indices do not overflow, and that loops with nontrivial
> >> exit condition are not infinite."
> >>
> >> The assumption on indices look
>>
>> IIUC that was slightly different: "This option tells the loop optimizer to
>> assume that loop indices do not overflow, and that loops with nontrivial
>> exit condition are not infinite."
>>
>> The assumption on indices looks unsafe indeed if it applied to unsigned
>> indices in non-empty l
On Sat, May 18, 2019 at 4:00 PM Marc Glisse wrote:
>
> (@Feng Xue, it is better to include testcases in your patches)
>
> >> I'm not a big fan of this patch. I'd rather be looking at either
> >> improving our analysis
>
> Better analysis cannot hurt.
>
> >> or adding attributes to the loops to he
(@Feng Xue, it is better to include testcases in your patches)
I'm not a big fan of this patch. I'd rather be looking at either
improving our analysis
Better analysis cannot hurt.
or adding attributes to the loops to help the analysis bits prove
termination.
There may not be a loop in the
On May 17, 2019 6:47:00 PM GMT+02:00, Jeff Law wrote:
>On 5/16/19 10:17 PM, Feng Xue OS wrote:
>> This patch is meant to give user a way to optimize away those empty
>loops which are impossible to be recognized by compiler, such as C++
>STL container-based loop,
>>
>> void f (std::map &m)
>>
On 5/16/19 10:17 PM, Feng Xue OS wrote:
> This patch is meant to give user a way to optimize away those empty loops
> which are impossible to be recognized by compiler, such as C++ STL
> container-based loop,
>
> void f (std::map &m)
> {
> for (auto it = m.begin (); it != m.end (
18 matches
Mail list logo
