On 05/03/2012 05:59 AM, Richard Guenther wrote:
the type can be removed from the structure and now there would be no
wastage. Is that reasonable?
types in ops is a bad idea (tried that once - heh), it wrecks too much generic
code.
heh, no doubt. As I Iooked at handling the generic atomics,
On Fri, Apr 27, 2012 at 2:31 PM, Andrew MacLeod wrote:
> On 04/27/2012 04:37 AM, Richard Guenther wrote:
>>
>> Since integral atomics are always of an unsigned type , I could switch
>> over
>> and use 'unsigned size' instead of 'tree fntype' for them (I will rename
>> it), but then things may be
On 04/27/2012 04:52 AM, Richard Guenther wrote:
hmm, yeah they always return a value. I was just copying the gimple_call
code... Why would we need to do this processing for a GIMPLE_CALL lhs and
not a GIMPLE_ATOMIC lhs?
GIMPLE_CALL lhs can be memory if the call returns an aggregate, similar
On 04/27/2012 04:37 AM, Richard Guenther wrote:
Since integral atomics are always of an unsigned type , I could switch over
and use 'unsigned size' instead of 'tree fntype' for them (I will rename
it), but then things may be more complicated when dealing with generic
atomics... those can be st
On Thu, Apr 26, 2012 at 10:07 PM, Andrew MacLeod wrote:
> On 04/05/2012 05:14 AM, Richard Guenther wrote:
>>
>> + static inline bool
>> + gimple_atomic_has_fail_order (const_gimple gs)
>> + {
>> + return gimple_atomic_kind (gs) == GIMPLE_ATOMIC_COMPARE_EXCHANGE;
>> + }
>>
>> btw, these kind of p
On Thu, Apr 26, 2012 at 7:53 PM, Andrew MacLeod wrote:
> On 04/05/2012 05:14 AM, Richard Guenther wrote:
>>
>>
>> Ok. Remember that you should use non-tree things if you can in GIMPLE
>> land. This probably means that both the size and the memmodel "operands"
>> should be
>>
>> + struct GTY(())
On 04/05/2012 05:14 AM, Richard Guenther wrote:
+ static inline bool
+ gimple_atomic_has_fail_order (const_gimple gs)
+ {
+ return gimple_atomic_kind (gs) == GIMPLE_ATOMIC_COMPARE_EXCHANGE;
+ }
btw, these kind of predicates look superfluous to me - if they are true
exactly for one atomic kind
On 04/05/2012 05:14 AM, Richard Guenther wrote:
Ok. Remember that you should use non-tree things if you can in GIMPLE
land. This probably means that both the size and the memmodel "operands"
should be
+ struct GTY(()) gimple_statement_atomic
+ {
+ /* [ WORD 1-8 ] */
+ struct gimple_state
On Tue, Apr 10, 2012 at 3:14 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Fri, Apr 6, 2012 at 10:13 AM, Richard Sandiford
>> wrote:
>>> Richard Guenther writes:
> They can affect shared memory in some ways like a call, but don't have
> many
> of the other attribute
Richard Guenther writes:
> On Fri, Apr 6, 2012 at 10:13 AM, Richard Sandiford
> wrote:
>> Richard Guenther writes:
They can affect shared memory in some ways like a call, but don't have many
of the other attributes of call. They are really more like an assignment
or
other o
On Fri, Apr 6, 2012 at 10:13 AM, Richard Sandiford
wrote:
> Richard Guenther writes:
>>> They can affect shared memory in some ways like a call, but don't have many
>>> of the other attributes of call. They are really more like an assignment or
>>> other operation with arbitrary shared memory si
Richard Guenther writes:
>> They can affect shared memory in some ways like a call, but don't have many
>> of the other attributes of call. They are really more like an assignment or
>> other operation with arbitrary shared memory side effects. I do hope to be
>> able to teach the optimizers the
On 04/05/2012 05:14 AM, Richard Guenther wrote:
Ok. I suppose having a GIMPLE_ATOMIC is fine then.
Thanks for all the feedback, I haven't really had to play in gimple land
much lately. Some of those routines I guessed at what to do in order to
get through initial compilation and your comment
On Wed, Apr 4, 2012 at 5:50 PM, Andrew MacLeod wrote:
> On 04/04/2012 10:33 AM, Richard Guenther wrote:
>>
>> On Wed, Apr 4, 2012 at 3:28 PM, Andrew MacLeod
>> wrote:
>> This is a WIP... that fntype fields is there for simplicity.. and no...
>> you can do a 1 byte atomic operation on a full wor
On 04/04/2012 10:33 AM, Richard Guenther wrote:
On Wed, Apr 4, 2012 at 3:28 PM, Andrew MacLeod wrote:
This is a WIP... that fntype fields is there for simplicity.. and no...
you can do a 1 byte atomic operation on a full word object if you want by
Oh, so you rather need a size or a mode speci
On Wed, Apr 4, 2012 at 4:32 PM, Richard Henderson wrote:
> On 04/04/2012 09:46 AM, Richard Guenther wrote:
>> If that is the only reason you can return two values by using a complex
>> or vector type (that would be only an IL implementation detail as far
>> as I can see).
>> We use that trick to g
On Wed, Apr 4, 2012 at 3:28 PM, Andrew MacLeod wrote:
> On 04/04/2012 04:45 AM, Richard Guenther wrote:
>>
>>
>> The fact that you need to touch every place that wants to look at memory
>> accesses shows that you are doing it wrong. Instead my plan was to
>> force _all_ memory accesses to GIMPLE_
On 04/04/2012 09:46 AM, Richard Guenther wrote:
> If that is the only reason you can return two values by using a complex
> or vector type (that would be only an IL implementation detail as far
> as I can see).
> We use that trick to get sincos () "sane" in our IL as well.
That would work if the t
On 04/04/2012 04:45 AM, Richard Guenther wrote:
The fact that you need to touch every place that wants to look at memory
accesses shows that you are doing it wrong. Instead my plan was to
force _all_ memory accesses to GIMPLE_ASSIGNs (yes, including those
we have now in calls). You're making a
Im not sure what happened to my original reply, so I'll resend it..
On 04/04/2012 09:28 AM, Andrew MacLeod wrote:
On 04/04/2012 04:45 AM, Richard Guenther wrote:
The fact that you need to touch every place that wants to look at memory
accesses shows that you are doing it wrong. Instead my pla
On 04/04/2012 09:28 AM, Andrew MacLeod wrote:
I wasn't excited about creating a new gimple statement, but it seemed
the best solution to my issues. In the end, I think this works very
cleanly. Im certainly open to better solutions. If there is a plan to
change gimple in some way that this d
On Wed, Apr 4, 2012 at 3:26 PM, Richard Henderson wrote:
> On 04/04/2012 04:45 AM, Richard Guenther wrote:
>> I suppose you do not want to use builtins because for primitive types you
>> end up with multiple statements for something "atomic"?
>
> The primary motivation is that builtins cannot retu
On 04/04/2012 04:45 AM, Richard Guenther wrote:
> I suppose you do not want to use builtins because for primitive types you
> end up with multiple statements for something "atomic"?
The primary motivation is that builtins cannot return two values.
Our current builtin returns one of the two values
On Tue, Apr 3, 2012 at 9:40 PM, Andrew MacLeod wrote:
> Here is my first step in promoting the __atomic builtins into gimple
> statements. I originally planned this as tree codes, but when prototyped it
> became obvious that a gimple statement was a far superior solution since we
> also need to d
24 matches
Mail list logo
