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

[Richard Biener <rguenther at suse dot de>]

On Thu, 10 Jul 2014, Jakub Jelinek wrote:

> On Thu, Jul 10, 2014 at 05:12:53PM +0200, Richard Biener wrote:
> > The following makes sure we fold the reads from string constants
> > created from folding memcpy (&foo, &string_cst[0], ...) to
> > eventually create similar code as if that memcpy folding wasn't
> > done (move-by-pieces).
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > 
> > Comments?
> > 
> > (yeah, those native_encode_expr improvement would be really nice,
> > eventually for a slightly different interface, native_encode_expr_part)
> 
> Don't think you need a new function for that, just add an optional argument
> to native_encode_expr, and propagate it to native_encode_string, which would
> if the new bool arg is true not do:
>   if (total_bytes > len)
>     return 0;
> but if total_bytes > len set total_bytes to len instead.
> Or, isn't your code only handling STRING_CSTs and nothing else?
> Then perhaps just export native_encode_string too and add the optional
> argument to that.

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 encodes (at most) [offset, offset + len] even when the actual
object is larger.  But yes, I'd share the actual workers and only
add native_encode_expr_part with the extra offset argument.

For the particular case native_encode_string is enough but I think
for constructor folding and constructor output we want to support
CONSTRUCTOR in native_encode_expr in the future.

Thus, I'm not sure if changing the semantics of native_encode_expr
is ok (or desirable with just an extra offset argument - if so
I can add an overload retaining the old semantic for the old
interface).

Richard.