Hi,
On Wed, 20 Jun 2012, Richard Guenther wrote:
> > Hmm? The original expression is an address, I have to build a MEM_REF
> > out of that, and the is_gimple_mem_ref_addr() just checked that that
> > very address (after going through fold) is not acceptable as MEM_REF
> > operand. So how coul
On Wed, Jun 20, 2012 at 5:09 PM, Michael Matz wrote:
> Hi,
>
> On Wed, 20 Jun 2012, Richard Guenther wrote:
>
>> > + exp = fold_build2 (MEM_REF,
>> > + build_array_type (char_type_node,
>> > + build_range_type (sizetype,
>> > +
Hi,
On Wed, 20 Jun 2012, Richard Guenther wrote:
> > + exp = fold_build2 (MEM_REF,
> > + build_array_type (char_type_node,
> > + build_range_type (sizetype,
> > + size_one_node,
> > le
On Wed, Jun 20, 2012 at 4:57 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 19 Jun 2012, Richard Guenther wrote:
>
>> The MEM_REF is acceptable to the tree oracle and it can extract
>> points-to information from it.
>>
>> Thus for simplicity unconditionally building the above is the best.
>
> But it do
Hi,
On Tue, 19 Jun 2012, Richard Guenther wrote:
> The MEM_REF is acceptable to the tree oracle and it can extract
> points-to information from it.
>
> Thus for simplicity unconditionally building the above is the best.
But it doesn't work, as refs_may_alias_p_1 only accepts certain operands
On Tue, Jun 19, 2012 at 12:13 PM, Michael Matz wrote:
> Hi,
>
> On Tue, 19 Jun 2012, Richard Guenther wrote:
>
>> > So, we have to build a memref always and rewrite its type to one
>> > representing the real size. Note that TYPE_MAX_VALUE may be NULL, so we
>> > don't need to check for 'len' bein
Hi,
On Tue, 19 Jun 2012, Richard Guenther wrote:
> > So, we have to build a memref always and rewrite its type to one
> > representing the real size. Note that TYPE_MAX_VALUE may be NULL, so we
> > don't need to check for 'len' being null or not.
> >
> > This fixes the C testcase (don't know abo
On Mon, Jun 18, 2012 at 4:59 PM, Michael Matz wrote:
> Hi,
>
> now that we regard MEM_EXPR as a conservative approximation for MEM_SIZE
> (and MEM_OFFSET) we must ensure that this is really the case. It isn't
> currently for the string expanders, as they use the MEM_REF (whose address
> was taken
Hi,
now that we regard MEM_EXPR as a conservative approximation for MEM_SIZE
(and MEM_OFFSET) we must ensure that this is really the case. It isn't
currently for the string expanders, as they use the MEM_REF (whose address
was taken) directly as the one to use for MEM_EXPR on the MEM rtx. Tha
