On Tue, 3 Dec 2013 12:16:39, Jeff Law wrote:
>
> On 12/03/13 11:40, Bernd Edlinger wrote:
>>>
>>
>> To me it does not feel like a hack at all, if the expansion needs to know in
>> what
>> context the result will be used, if it is in an LHS or in a RHS or if the
>> address of
>> the memory is needed.
> Expansion needs some context and it's currently passed into expand_expr
> via a variety of methods. Most are documented at the start of
> expand_expr_real. It's unclean, but that doesn't mean we should make it
> worse. Adding more context is something we should think long and hard
> about.
>
> Eric's comment that we have a non-BLKmode object with a variable size I
> think is critical. I'm pretty sure that's not a well-defined object.
> Given a variable sized object that is not BLKmode, how can we reliably
> get its size (you can't, that's part of the reason why BLKmode exists)
>
> I'd pull on that thread.
>
Well, there are examples of invalid C that produce invalid Code (without
warning).
Garbage-In-Garbage-Out, That's OK.
Then there is this one:
struct S {
X a;
Y b[0];
};
it has the mode of X, which is questionable. I could detect that in expansion
and only set expand_reference if b is accessed. Maybe.
But then we have:
struct S {
Y b[1];
};
it has the Mode of Y
and even...
struct S {
Y b[2];
};
this one has an Integer Mode of size(Y)*2
I have no idea how to detect this in expansion, and how to handle
for instance a volatile b correctly. And I cannot declare that data structure
invalid.
Of course this depends on the back-end, what modes it supports.
And if there are movmisalign optabs, or SLOW_UNALIGNED_ACCESS.
>>
>> To make that perfectly clear, I just want to help.
> Understood and its greatly appreciated.
>
>>
>> And even if I commit something, it can be reverted anytime, when we have
>> something better.
> We try to get it right the first time :-) Reverting bits is undesirable
> and virtually impossible if it gets out into a release.
>
> jeff
>
