On 01/26/2016 09:36 AM, Bin.Cheng wrote:
On Tue, Jan 26, 2016 at 4:26 PM, Jeff Law wrote:
On 01/26/2016 02:28 AM, Bin.Cheng wrote:
Yes, loop invariant now increased invariant cost if the invariant
can't be propagated into address expression. Problem is we check
propagation by simply replacin
On Tue, Jan 26, 2016 at 4:26 PM, Jeff Law wrote:
> On 01/26/2016 02:28 AM, Bin.Cheng wrote:
>>
>> Yes, loop invariant now increased invariant cost if the invariant
>> can't be propagated into address expression. Problem is we check
>> propagation by simply replacing use with def in memory referen
On 01/26/2016 02:28 AM, Bin.Cheng wrote:
Yes, loop invariant now increased invariant cost if the invariant
can't be propagated into address expression. Problem is we check
propagation by simply replacing use with def in memory reference then
verifying result insn with verify_changes. Apparently
On Tue, Jan 26, 2016 at 1:51 PM, Bin.Cheng wrote:
> On Tue, Jan 26, 2016 at 12:56 PM, Bernd Schmidt
> wrote:
>> On 01/26/2016 10:48 AM, Bin.Cheng wrote:
>>>
>>> Yes, I moved whole loop pass (also the pass_web) after combine and it
>>> worked. A combine pass before loop-invariant can fix this pr
On Tue, Jan 26, 2016 at 12:56 PM, Bernd Schmidt wrote:
> On 01/26/2016 10:48 AM, Bin.Cheng wrote:
>>
>> Yes, I moved whole loop pass (also the pass_web) after combine and it
>> worked. A combine pass before loop-invariant can fix this problem.
>> Below passes are currently between loop transform
On 01/26/2016 10:48 AM, Bin.Cheng wrote:
Yes, I moved whole loop pass (also the pass_web) after combine and it
worked. A combine pass before loop-invariant can fix this problem.
Below passes are currently between loop transform and combine:
NEXT_PASS (pass_web);
NEXT_PASS (pass_rt
On Mon, Jan 25, 2016 at 8:05 PM, Bernd Schmidt wrote:
> On 01/25/2016 08:51 PM, Jeff Law wrote:
>>
>> No, the combiner works within a basic block only. There was a group, I
>> believe in Moscow, that worked on a cross-block combiner. It was
>> discussed at the Cauldron in California a few years
On Mon, Jan 25, 2016 at 7:51 PM, Jeff Law wrote:
> On 01/25/2016 11:42 AM, Bin.Cheng wrote:
>>
>>
>> Yuri Rumyantsev suggested we may add a hook to handle GOT related
>> instruction propagation specially so it won't be hoisted out. Is a
>> hook at this stage sounds feasible?
>
> I think that woul
On 01/25/2016 08:51 PM, Jeff Law wrote:
No, the combiner works within a basic block only. There was a group, I
believe in Moscow, that worked on a cross-block combiner. It was
discussed at the Cauldron in California a few years back. I don't know
if they did any further work on those ideas.
I
On 01/25/2016 11:42 AM, Bin.Cheng wrote:
Yuri Rumyantsev suggested we may add a hook to handle GOT related
instruction propagation specially so it won't be hoisted out. Is a
hook at this stage sounds feasible?
I think that would be a mistake. ISTM this really needs to be cost driven.
Also
Hi,
In revision 229402, I added logic in loop-invariant.c to check if a
look invariant can be forward propagated to memory references in the
same loop; and increase loop invariant cost if the answer is no. I
think this is a reasonable change. Some targets like AArch64 can
benefit from it because
11 matches
Mail list logo
