On Fri, 17 Jun 2011, Michael Matz wrote:
Hi,
On Thu, 16 Jun 2011, Richard Guenther wrote:
If people want to not create useless conversions in the first place,
though, I suspect there are lots of places that create useless
conversions in the compiler.
Yeah, the above looks it
Hi,
On Thu, 16 Jun 2011, Richard Guenther wrote:
If people want to not create useless conversions in the first place,
though, I suspect there are lots of places that create useless
conversions in the compiler.
Yeah, the above looks it comes from the frontends - gimplification
should
On Wed, Jun 15, 2011 at 7:46 PM, Mike Stump mikest...@comcast.net wrote:
On Jun 15, 2011, at 2:04 AM, Richard Guenther wrote:
This VIEW_CONVERT_EXPR looks useless - in fact useless_type_conversion_p
will tell you that, so you can omit it.
So, I tracked down who created it:
tree
On Tue, 14 Jun 2011, Mike Stump wrote:
On Jun 13, 2011, at 3:57 AM, Richard Guenther wrote:
That's not exactly an example - I can't think of how you want or need
to use VIEW_CONVERT_EXPRs to implement said divmod instruction or why
you would need anything special for the _argument_ of said
On Jun 15, 2011, at 2:04 AM, Richard Guenther wrote:
This VIEW_CONVERT_EXPR looks useless - in fact useless_type_conversion_p
will tell you that, so you can omit it.
So, I tracked down who created it:
tree
convert_to_vector (tree type, tree expr)
{
switch (TREE_CODE (TREE_TYPE (expr)))
{
On Mon, 13 Jun 2011, Jason Merrill wrote:
On 06/13/2011 06:51 AM, Richard Guenther wrote:
But I suppose you want the array-ref be folded to a constant eventually?
Right.
I'm not going to keep arguing about VIEW_CONVERT_EXPR, but that brings me back
to my original question: is it OK to
On Jun 13, 2011, at 3:57 AM, Richard Guenther wrote:
That's not exactly an example - I can't think of how you want or need
to use VIEW_CONVERT_EXPRs to implement said divmod instruction or why
you would need anything special for the _argument_ of said instruction.
Oh, I completely
On Mon, Jun 13, 2011 at 12:10 AM, Jason Merrill ja...@redhat.com wrote:
On 06/12/2011 06:59 AM, Richard Guenther wrote:
The please provide a specification on what a VIEW_CONVERT_EXPR does
to type-based alias analysis.
If the alias set of the VIEW_CONVERT_EXPR type the same as the set for the
On Mon, Jun 13, 2011 at 5:17 AM, Mike Stump mikest...@comcast.net wrote:
On Jun 12, 2011, at 3:55 AM, Richard Guenther wrote:
In almost all cases(*) the need for a lvalue VIEW_CONVERT_EXPR can be avoided
by moving the VIEW_CONVERT_EXPR to the rvalue assigned too it. Remember that
On 06/13/2011 06:51 AM, Richard Guenther wrote:
But I suppose you want the array-ref be folded to a constant eventually?
Right.
I'm not going to keep arguing about VIEW_CONVERT_EXPR, but that brings
me back to my original question: is it OK to add a permissive mode to
the function, or
On Sat, Jun 11, 2011 at 7:45 PM, Mike Stump mikest...@comcast.net wrote:
On Jun 10, 2011, at 7:20 AM, Richard Guenther wrote:
On Fri, 10 Jun 2011, Jason Merrill wrote:
On 06/10/2011 10:03 AM, Richard Guenther wrote:
*((volatile int *)a[0] + 1)
It would be correct to fold it to
On 06/12/2011 06:59 AM, Richard Guenther wrote:
The please provide a specification on what a VIEW_CONVERT_EXPR does
to type-based alias analysis.
If the alias set of the VIEW_CONVERT_EXPR type the same as the set for
the operand, ignore it; if it's a subset, handle it like a
COMPONENT_REF;
On Jun 12, 2011, at 4:03 AM, Richard Guenther wrote:
Btw, see tree.def which says
/* Represents viewing something of one type as being of a second type.
This corresponds to an Unchecked Conversion in Ada and roughly to
the idiom *(type2 *)X in C. The only operand is the value to be
On Jun 12, 2011, at 3:55 AM, Richard Guenther wrote:
In almost all cases(*) the need for a lvalue VIEW_CONVERT_EXPR can be avoided
by moving the VIEW_CONVERT_EXPR to the rvalue assigned too it. Remember that
VIEW_CONVERT_EXPR always conver the full object and are not allowed to
change sizes.
On Jun 10, 2011, at 7:20 AM, Richard Guenther wrote:
On Fri, 10 Jun 2011, Jason Merrill wrote:
On 06/10/2011 10:03 AM, Richard Guenther wrote:
*((volatile int *)a[0] + 1)
It would be correct to fold it to
VIEW_CONVERT_EXPRvolatile int,a[1]
No, it wouldn't be correct. It isn't
On Thu, 9 Jun 2011, Jason Merrill wrote:
On 06/07/2011 10:24 AM, Jason Merrill wrote:
On 06/07/2011 10:05 AM, Richard Guenther wrote:
In that case you could do what Jakub suggested - but only for rvalues
of course.
Right, and I need to handle lvalues as well.
Can't you instead
On 06/10/2011 04:35 AM, Richard Guenther wrote:
I'm out of good suggestions ;) You can do the same-qualifier matching
and simply have a mismatched array element vs. array-ref type.
But I need to allow different qualifiers, too.
We could also argue that whoever calls fold_indirect_ref_1 with
On 06/10/2011 10:03 AM, Richard Guenther wrote:
*((volatile int *)a[0] + 1)
It would be correct to fold it to
VIEW_CONVERT_EXPRvolatile int,a[1]
No, it wouldn't be correct. It isn't correct to fold it to an array-ref
that isn't volatile.
Hmm? The C expression produces a volatile int
On Fri, 10 Jun 2011, Jason Merrill wrote:
On 06/10/2011 10:03 AM, Richard Guenther wrote:
*((volatile int *)a[0] + 1)
It would be correct to fold it to
VIEW_CONVERT_EXPRvolatile int,a[1]
No, it wouldn't be correct. It isn't correct to fold it to an array-ref
that isn't
On 06/10/2011 10:20 AM, Richard Guenther wrote:
no, a VIEW_CONVERT_EXPR is generally not an lvalue (fold for example
would turn the above to (volatile int) a[1]).
Really? Seems like it would be a lot more useful if it were an lvalue.
I guess I'll just copy the whole function into the front
On 06/07/2011 10:24 AM, Jason Merrill wrote:
On 06/07/2011 10:05 AM, Richard Guenther wrote:
In that case you could do what Jakub suggested - but only for rvalues
of course.
Right, and I need to handle lvalues as well.
Can't you instead adjust the type you feed to fold_indirect_ref_1 in
the
On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill ja...@redhat.com wrote:
In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an ARRAY_REF
because T != unsigned. Even if it were just a typedef to unsigned, that
isn't close enough, but in this case it's a typedef to const unsigned.
On Tue, Jun 07, 2011 at 12:19:59PM +0200, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill ja...@redhat.com wrote:
In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an ARRAY_REF
because T != unsigned. Even if it were just a typedef to unsigned, that
isn't
On Tue, Jun 7, 2011 at 12:27 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Jun 07, 2011 at 12:19:59PM +0200, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill ja...@redhat.com wrote:
In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an
ARRAY_REF
On Tue, 7 Jun 2011, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 12:27 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Jun 07, 2011 at 12:19:59PM +0200, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill ja...@redhat.com wrote:
In the testcase, fold_indirect_ref_1
Hi,
On Tue, 7 Jun 2011, Richard Guenther wrote:
fold_convert_loc it to the expected type, while the middle-end has
the notion of useless type conversions, fold-const.c is also used by
FEs and I think it is expected to have the types exactly matching.
So (T)s1[10] instead of s1[10]
On Tue, 7 Jun 2011, Michael Matz wrote:
Hi,
On Tue, 7 Jun 2011, Richard Guenther wrote:
fold_convert_loc it to the expected type, while the middle-end has
the notion of useless type conversions, fold-const.c is also used by
FEs and I think it is expected to have the types
On 06/07/2011 06:19 AM, Richard Guenther wrote:
I _think_ that you can unconditionally change the code to do
TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
TYPE_QUALS (t1) == TYPE_QUALS (t2)
now, I'm not sure if for the testcase T and unsigned differ in qualifiers.
Do they?
Hmm, I
On Tue, Jun 7, 2011 at 3:55 PM, Jason Merrill ja...@redhat.com wrote:
On 06/07/2011 06:19 AM, Richard Guenther wrote:
I _think_ that you can unconditionally change the code to do
TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
TYPE_QUALS (t1) == TYPE_QUALS (t2)
now, I'm not sure if
On 06/07/2011 10:05 AM, Richard Guenther wrote:
In that case you could do what Jakub suggested - but only for rvalues
of course.
Right, and I need to handle lvalues as well.
I'm not sure if we already avoid calling the folding where we
require lvalues.
No, we don't.
Can't you instead
In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an
ARRAY_REF because T != unsigned. Even if it were just a typedef to
unsigned, that isn't close enough, but in this case it's a typedef to
const unsigned.
I'm not sure what the type coherence rules are for ARRAY_REF. Is it
31 matches
Mail list logo
