<div dir="ltr">Yeah, this looks like a promising direction.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 15, 2014 at 1:51 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 14 May 2014 17:40, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>

> What about making a new LValue type that doesn't have an address?  At the<br>
> source level, current_stack_pointer is an lvalue that can be stored to.  If<br>
> we ever want to add support for the 'register' class specifier as it was<br>
> originally designed, we will need a new 'Register' LValue type that can be<br>
> read from and stored to.  We probably don't want to do that, but it feels<br>
> like the right model to me.<br>
<br>
</div>Hi Reid,<br>
<br>
I think I got it. Creating a new type of LValue wasn't that much<br>
invasive after all, though I don't know how folks feel about it.<br>
Attached is a patch that makes it work (but breaks other things and<br>
has more hacks than I'd consider healthy). Can you have a look and see<br>
if that's (more or less) what you had in mind? If that's the right<br>
angle, I'll fix the bugs and add some tests.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div>