Re: [PATCH] Fix PR61762, reads from string constants

[Richard Biener <rguenther at suse dot de>]

On Fri, 11 Jul 2014, Jakub Jelinek wrote:

> On Fri, Jul 11, 2014 at 10:00:01AM +0200, Richard Biener wrote:
> > I started with adding an optional arg to native_encode_expr but then
> > figured that all the current workers return failure if the entire
> > expr doesn't fit within 'len'.  But what I want is a native_encode_expr
> 
> That is because the functions were written for VIEW_CONVERT_EXPR folding
> where it is expected that both the types are the same size, and it doesn't
> make sense to spend too much time on large stuff that doesn't fit into
> the fold_view_convert_expr's fixed size buffer.  Now, for your case
> the sizes aren't the same and thus partial data is just fine, because
> what native_interpret_expr will do is small fixed size.
> So I don't see a problem with not returning NULL and instead handling the
> partial store into buffer if you ask for it through optional argument
> (doing it always would be fine for fold_view_convert_expr assuming nobody
> feeds us different sized argument vs. VCE type, but e.g.
> tree-loop-distribution.c certainly appreciates if we return NULL for large
> things, because if it had just partial buffer, it would not be able to
> verify what it is looking for).

Yeah, if you pass 'offset' then 'len' suddenly changes semantics
from specifying the buffer size to specifying the desired amount
of encoded data ... (which the present interface computes for you,
the caller doesn't even need to know how large it is).

The question is also if I ask native_encode_expr to produce
data for [offset, offset + len] but the object only contains
part of it - thus the tail is 'undefined' - do we want to fail
or simply feed (undefined) "garbage" to the following
native_interpret_expr?  (yes, native_encode_expr will of course
return sth < len in this case)

Richard.