On Thu, May 11, 2017 at 2:15 PM, Richard Biener
wrote:
> On Thu, May 11, 2017 at 2:14 PM, Richard Biener
> wrote:
>> On Thu, May 11, 2017 at 1:15 PM, Robin Dapp wrote:
>>> Included the requested changes in the patches (to follow). I removed
>>> the alignment count check now altogether.
>>>
On Thu, May 11, 2017 at 2:14 PM, Richard Biener
wrote:
> On Thu, May 11, 2017 at 1:15 PM, Robin Dapp wrote:
>> Included the requested changes in the patches (to follow). I removed
>> the alignment count check now altogether.
>>
>>> I'm not sure why you test for unlimited_cost_model here as I sai
On Thu, May 11, 2017 at 1:15 PM, Robin Dapp wrote:
> Included the requested changes in the patches (to follow). I removed
> the alignment count check now altogether.
>
>> I'm not sure why you test for unlimited_cost_model here as I said
>> elsewhere I'm not sure
>> what not cost modeling means fo
Included the requested changes in the patches (to follow). I removed
the alignment count check now altogether.
> I'm not sure why you test for unlimited_cost_model here as I said
> elsewhere I'm not sure
> what not cost modeling means for static decisions. The purpose of
> unlimited_cost_model
>
On Mon, May 8, 2017 at 6:11 PM, Robin Dapp wrote:
>> So the new part is the last point? There's a lot of refactoring in
> 3/3 that
>> makes it hard to see what is actually changed ... you need to resist
>> in doing this, it makes review very hard.
>
> The new part is actually spread across the t
> So the new part is the last point? There's a lot of refactoring in
3/3 that
> makes it hard to see what is actually changed ... you need to resist
> in doing this, it makes review very hard.
The new part is actually spread across the three last "-"s. Attached is
a new version of [3/3] split u
On Thu, May 4, 2017 at 10:59 AM, Robin Dapp wrote:
> Hi,
>
>> This one only works for known misalignment, otherwise it's overkill.
>>
>> OTOH if with some refactoring we can end up using a single cost model
>> that would be great. That is for the SAME_ALIGN_REFS we want to
>> choose the unknown m
Hi,
> This one only works for known misalignment, otherwise it's overkill.
>
> OTOH if with some refactoring we can end up using a single cost model
> that would be great. That is for the SAME_ALIGN_REFS we want to
> choose the unknown misalignment with the maximum number of
> SAME_ALIGN_REFS. A
On Wed, Apr 12, 2017 at 9:50 AM, Robin Dapp wrote:
>> Note I was very conservative here to allow store bandwidth starved
>> CPUs to benefit from aligning a store.
>>
>> I think it would be reasonable to apply the same heuristic to the
>> store case that we only peel for same cost if peeling would
> Note I was very conservative here to allow store bandwidth starved
> CPUs to benefit from aligning a store.
>
> I think it would be reasonable to apply the same heuristic to the
> store case that we only peel for same cost if peeling would at least
> align two refs.
Do you mean checking if peel
On April 11, 2017 4:57:29 PM GMT+02:00, "Bin.Cheng"
wrote:
>On Tue, Apr 11, 2017 at 3:38 PM, Robin Dapp
>wrote:
>> Hi,
>>
>> when looking at various vectorization examples on s390x I noticed
>that
>> we still peel vf/2 iterations for alignment even though vectorization
>> costs of unaligned load
On Tue, Apr 11, 2017 at 4:03 PM, Robin Dapp wrote:
> Hi Bin,
>
>> Seems Richi added code like below comparing costs between aligned and
>> unsigned loads, and only peeling if it's beneficial:
>>
>> /* In case there are only loads with different unknown misalignments,
>> use
>> peel
Hi Bin,
> Seems Richi added code like below comparing costs between aligned and
> unsigned loads, and only peeling if it's beneficial:
>
> /* In case there are only loads with different unknown misalignments,
> use
> peeling only if it may help to align other accesses in the loop
On Tue, Apr 11, 2017 at 3:38 PM, Robin Dapp wrote:
> Hi,
>
> when looking at various vectorization examples on s390x I noticed that
> we still peel vf/2 iterations for alignment even though vectorization
> costs of unaligned loads and stores are the same as normal loads/stores.
>
> A simple exampl
Hi,
when looking at various vectorization examples on s390x I noticed that
we still peel vf/2 iterations for alignment even though vectorization
costs of unaligned loads and stores are the same as normal loads/stores.
A simple example is
void foo(int *restrict a, int *restrict b, unsigned int n)
15 matches
Mail list logo
