On Thu, Jun 29, 2017 at 12:32 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Wed, Jun 28, 2017 at 3:36 PM, Richard Sandiford
>> wrote:
>>> dr_analyze_innermost had a "struct loop *nest" parameter that acted
>>> like a boolean. This was added in r179161, with the idea that a
>>> nul
Richard Biener writes:
> On Wed, Jun 28, 2017 at 3:36 PM, Richard Sandiford
> wrote:
>> dr_analyze_innermost had a "struct loop *nest" parameter that acted
>> like a boolean. This was added in r179161, with the idea that a
>> null nest selected BB-level analysis rather than loop analysis.
>>
>>
On Wed, Jun 28, 2017 at 3:36 PM, Richard Sandiford
wrote:
> dr_analyze_innermost had a "struct loop *nest" parameter that acted
> like a boolean. This was added in r179161, with the idea that a
> null nest selected BB-level analysis rather than loop analysis.
>
> The handling seemed strange thoug
On Wed, Jun 28, 2017 at 8:06 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Wed, Jun 28, 2017 at 5:56 PM, Richard Sandiford
>> wrote:
>>> "Bin.Cheng" writes:
Question is what would happen if simple_iv succeeds with non-ZERO step
when called with nest==NULL? The patch skips
"Bin.Cheng" writes:
> On Wed, Jun 28, 2017 at 5:56 PM, Richard Sandiford
> wrote:
>> "Bin.Cheng" writes:
>>> Question is what would happen if simple_iv succeeds with non-ZERO step
>>> when called with nest==NULL? The patch skips simple_iv and forces
>>> ZERO step?
>>
>> Yeah, I mentioned that i
On Wed, Jun 28, 2017 at 5:56 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Wed, Jun 28, 2017 at 3:04 PM, Richard Sandiford
>> wrote:
>>> "Bin.Cheng" writes:
On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
wrote:
> Index: gcc/tree-data-ref.c
> ===
"Bin.Cheng" writes:
> On Wed, Jun 28, 2017 at 3:04 PM, Richard Sandiford
> wrote:
>> "Bin.Cheng" writes:
>>> On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
>>> wrote:
Index: gcc/tree-data-ref.c
===
--- gcc/tree-d
On Wed, Jun 28, 2017 at 3:04 PM, Richard Sandiford
wrote:
> "Bin.Cheng" writes:
>> On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
>> wrote:
>>> Index: gcc/tree-data-ref.c
>>> ===
>>> --- gcc/tree-data-ref.c 2017-06-28 14:33:41.2
"Bin.Cheng" writes:
> On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
> wrote:
>> Index: gcc/tree-data-ref.c
>> ===
>> --- gcc/tree-data-ref.c 2017-06-28 14:33:41.294720044 +0100
>> +++ gcc/tree-data-ref.c 2017-06-28 14:35:30.4751
On Wed, Jun 28, 2017 at 2:36 PM, Richard Sandiford
wrote:
> Index: gcc/tree-data-ref.c
> ===
> --- gcc/tree-data-ref.c 2017-06-28 14:33:41.294720044 +0100
> +++ gcc/tree-data-ref.c 2017-06-28 14:35:30.475155670 +0100
> @@ -749,15 +749
dr_analyze_innermost had a "struct loop *nest" parameter that acted
like a boolean. This was added in r179161, with the idea that a
null nest selected BB-level analysis rather than loop analysis.
The handling seemed strange though. If the DR was part of a loop,
we still tried to express the base
11 matches
Mail list logo