On Tue, Mar 29, 2011 at 2:44 PM, Richard Sandiford
wrote:
> Richard Sandiford writes:
>> Richard Guenther writes:
>>> Well, I meant if the user compiles with -msse, declares such a
>>> global var (which means it gets V4SFmode and not BLKmode)
>>> and then uses it in a function where he explicitl
Richard Sandiford writes:
> Richard Guenther writes:
>> Well, I meant if the user compiles with -msse, declares such a
>> global var (which means it gets V4SFmode and not BLKmode)
>> and then uses it in a function where he explicitly disables SSE
>> then something is wrong. If he declares a BLKm
Richard Guenther writes:
> On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford
> wrote:
>> Richard Guenther writes:
> For your case in question the vectorizer would create local vars with
> that mode, knowing it is supported, so I don't see big problems for
> that particular case.
>>>
On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
>>>
>>> The problem is that I'd like
Richard Guenther writes:
>>> For your case in question the vectorizer would create local vars with
>>> that mode, knowing it is supported, so I don't see big problems for
>>> that particular case.
>>
>> The problem is that I'd like to use this for intrinsics as well as for
>> automatic vectorisati
On Wed, Mar 23, 2011 at 2:01 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>>> Hmm, but if we do that, when is it correct to look at TYPE_MODE?
>>
>> Most of the tree passes shouldn't care about TYPE_MODE (nor
>> DECL_MODE) and on RTL we shouldn't need to care about trees.
>
> It sounds
Richard Guenther writes:
>> Hmm, but if we do that, when is it correct to look at TYPE_MODE?
>
> Most of the tree passes shouldn't care about TYPE_MODE (nor
> DECL_MODE) and on RTL we shouldn't need to care about trees.
It sounds like you think it would be better to get rid of TYPE_MODE.
I can se
On Wed, Mar 23, 2011 at 1:18 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
>> wrote:
>>> Richard Guenther writes:
But as you have partial defs of the vector lane array the simplest
approach is probably to not make them a
Richard Guenther writes:
> On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
> wrote:
>> Richard Guenther writes:
>>> But as you have partial defs of the vector lane array the simplest
>>> approach is probably to not make them a register. Be prepared
>>> for some surprises during RTL expansio
On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> But as you have partial defs of the vector lane array the simplest
>> approach is probably to not make them a register. Be prepared
>> for some surprises during RTL expansion though ;)
>
> OK. It's there I'
Richard Guenther writes:
> But as you have partial defs of the vector lane array the simplest
> approach is probably to not make them a register. Be prepared
> for some surprises during RTL expansion though ;)
OK. It's there I'd like to start, specifically with:
These arrays of vectors would
>> ...Ira would know best, but I don't think it would be used for this
>> kind of loop. It would be more something like:
>>
>> for (i=0; i> X[i] = Y[i].red + Y[i].blue + Y[i].green;
>>
>> (not a realistic example). You'd then have:
>>
>> compoundY = __builtin_load_lanes (Y);
>> red =
On Tue, Mar 22, 2011 at 8:43 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> Simple. Just make them registers anyway (I did that in the past
>> when working on middle-end arrays). You'd set DECL_GIMPLE_REG_P
>> on the decl.
>
> OK, thanks, I'll give that a go. TBH, I'm still hopeful
Richard Guenther writes:
> Simple. Just make them registers anyway (I did that in the past
> when working on middle-end arrays). You'd set DECL_GIMPLE_REG_P
> on the decl.
OK, thanks, I'll give that a go. TBH, I'm still hopeful we can
do without it, because we do seem to cope quite well as thi
On Tue, Mar 22, 2011 at 5:52 PM, Richard Sandiford
wrote:
> This is an RFC about adding gimple and optab support for things like
> ARM's load-lane and store-lane instructions. It builds on an earlier
> discussion between Ira and Julian, with the aim of allowing these
> instructions to be used by
This is an RFC about adding gimple and optab support for things like
ARM's load-lane and store-lane instructions. It builds on an earlier
discussion between Ira and Julian, with the aim of allowing these
instructions to be used by the vectoriser.
These instructions operate on N vector registers o
16 matches
Mail list logo
