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.
