https://codereview.appspot.com/87810048/diff/60001/go/backend.h File go/backend.h (right): https://codereview.appspot.com/87810048/diff/60001/go/backend.h#newcode660 go/backend.h:660: push_function_context(Bfunction* function, Location start_location, We shouldn't need this in ...
https://codereview.appspot.com/87810048/diff/60001/go/backend.h
File go/backend.h (right):
https://codereview.appspot.com/87810048/diff/60001/go/backend.h#newcode660
go/backend.h:660: push_function_context(Bfunction* function, Location
start_location,
We shouldn't need this in the backend interface. This is how GCC works, but
when we're converting to the backend representation we should only ever have one
function to consider: the one being converted. So there is no need to push or
pop anything. And there should be no need to set a function context or
anything.
https://codereview.appspot.com/87810048/diff/60001/go/backend.h#newcode673
go/backend.h:673: process_function(Bfunction* function, bool finalize) = 0;
Can we just call this from write_global_definitions?
The finalize parameter is there for the initialization function. It's different
because it's currently built entirely in the backend representation. I wonder
if we could instead build it as a Go function (a separate CL for that, I think).
If there is some reason that it can't be a Go function, then I think there
should probably be a separate backend method for it. The finalize parameter
here doesn't make much sense.
https://codereview.appspot.com/87810048/diff/60001/go/expressions.cc File go/expressions.cc (left): https://codereview.appspot.com/87810048/diff/60001/go/expressions.cc#oldcode4664 go/expressions.cc:4664: error_at(location, "constant addition overflow"); You need to sync to ...
Might be worth splitting out the changes to expressions.cc into a smaller CL.
Might also be worth rewriting the way the initialization function is handled in
a different CL. Change it from being entirely backend to being a regular Go
function, albeit a generated one.
https://codereview.appspot.com/87810048/diff/90001/go/backend.h
File go/backend.h (right):
https://codereview.appspot.com/87810048/diff/90001/go/backend.h#newcode658
go/backend.h:658: // success, false on failure.
I looked at the parameter_variable and local_variable backend methods, and I see
that they already take a function argument, and use it to set the DECL_CONTEXT.
So now I'm wondering whether we need to do this at all. What goes wrong if we
don't have a method like this?
https://codereview.appspot.com/87810048/diff/90001/go/backend.h#newcode666
go/backend.h:666: write_init_function(Bfunction* initfn, Location
start_location,
What if we add the initialization function to the list we pass to
write_global_definitions? If we do that, do we still need a function like this?
https://codereview.appspot.com/87810048/diff/90001/go/gogo.cc
File go/gogo.cc (right):
https://codereview.appspot.com/87810048/diff/90001/go/gogo.cc#newcode1178
go/gogo.cc:1178: if (!this->backend()->set_function_context(init_fndecl, loc,
loc))
We're currently dealing with the initialization function entirely as a backend
entity. If we instead create a Named_object for it, as we do in places like
Build_recover_thunks::function, then we will have something we can pass to
var->get_init_block. Then we shouldn't need to call set_function_context here.
https://codereview.appspot.com/87810048/diff/90001/go/gogo.h
File go/gogo.h (right):
https://codereview.appspot.com/87810048/diff/90001/go/gogo.h#newcode2220
go/gogo.h:2220: // The backend representation for this object if it is a
NAMED_OBJECT_TYPE.
I think these can all move into the appropriate elements of u_. Put
backend_type_ in Named_type (actually I think it is already there anyhow), put
backend_const_ in Named_constant, put backend_function_ in Function (that one is
already there also).
FYI, the bulk of the changes to expressions.cc have been split into https://codereview.appspot.com/88080048/ and https://codereview.appspot.com/88950043/ ...
https://codereview.appspot.com/87810048/diff/90001/go/backend.h File go/backend.h (right): https://codereview.appspot.com/87810048/diff/90001/go/backend.h#newcode658 go/backend.h:658: // success, false on failure. On 2014/04/17 15:29:53, iant ...
9 years, 12 months ago
(2014-04-24 21:39:25 UTC)
#8
https://codereview.appspot.com/87810048/diff/90001/go/backend.h
File go/backend.h (right):
https://codereview.appspot.com/87810048/diff/90001/go/backend.h#newcode658
go/backend.h:658: // success, false on failure.
On 2014/04/17 15:29:53, iant wrote:
> I looked at the parameter_variable and local_variable backend methods, and I
see
> that they already take a function argument, and use it to set the
DECL_CONTEXT.
> So now I'm wondering whether we need to do this at all. What goes wrong if we
> don't have a method like this?
Done.
https://codereview.appspot.com/87810048/diff/90001/go/backend.h#newcode666
go/backend.h:666: write_init_function(Bfunction* initfn, Location
start_location,
On 2014/04/17 15:29:53, iant wrote:
> What if we add the initialization function to the list we pass to
> write_global_definitions? If we do that, do we still need a function like
this?
Done.
https://codereview.appspot.com/87810048/diff/90001/go/gogo.cc
File go/gogo.cc (right):
https://codereview.appspot.com/87810048/diff/90001/go/gogo.cc#newcode1178
go/gogo.cc:1178: if (!this->backend()->set_function_context(init_fndecl, loc,
loc))
On 2014/04/17 15:29:53, iant wrote:
> We're currently dealing with the initialization function entirely as a backend
> entity. If we instead create a Named_object for it, as we do in places like
> Build_recover_thunks::function, then we will have something we can pass to
> var->get_init_block. Then we shouldn't need to call set_function_context
here.
Done.
https://codereview.appspot.com/87810048/diff/90001/go/gogo.h
File go/gogo.h (right):
https://codereview.appspot.com/87810048/diff/90001/go/gogo.h#newcode2220
go/gogo.h:2220: // The backend representation for this object if it is a
NAMED_OBJECT_TYPE.
On 2014/04/17 15:29:53, iant wrote:
> I think these can all move into the appropriate elements of u_. Put
> backend_type_ in Named_type (actually I think it is already there anyhow), put
> backend_const_ in Named_constant, put backend_function_ in Function (that one
is
> already there also).
Done.
9 years, 12 months ago
(2014-04-24 21:42:30 UTC)
#9
On 2014/04/24 21:39:25, cmang wrote:
> https://codereview.appspot.com/87810048/diff/90001/go/backend.h
> File go/backend.h (right):
>
> https://codereview.appspot.com/87810048/diff/90001/go/backend.h#newcode658
> go/backend.h:658: // success, false on failure.
> On 2014/04/17 15:29:53, iant wrote:
> > I looked at the parameter_variable and local_variable backend methods, and I
> see
> > that they already take a function argument, and use it to set the
> DECL_CONTEXT.
> > So now I'm wondering whether we need to do this at all. What goes wrong if
we
> > don't have a method like this?
>
> Done.
>
> https://codereview.appspot.com/87810048/diff/90001/go/backend.h#newcode666
> go/backend.h:666: write_init_function(Bfunction* initfn, Location
> start_location,
> On 2014/04/17 15:29:53, iant wrote:
> > What if we add the initialization function to the list we pass to
> > write_global_definitions? If we do that, do we still need a function like
> this?
>
> Done.
>
> https://codereview.appspot.com/87810048/diff/90001/go/gogo.cc
> File go/gogo.cc (right):
>
> https://codereview.appspot.com/87810048/diff/90001/go/gogo.cc#newcode1178
> go/gogo.cc:1178: if (!this->backend()->set_function_context(init_fndecl, loc,
> loc))
> On 2014/04/17 15:29:53, iant wrote:
> > We're currently dealing with the initialization function entirely as a
backend
> > entity. If we instead create a Named_object for it, as we do in places like
> > Build_recover_thunks::function, then we will have something we can pass to
> > var->get_init_block. Then we shouldn't need to call set_function_context
> here.
>
> Done.
>
> https://codereview.appspot.com/87810048/diff/90001/go/gogo.h
> File go/gogo.h (right):
>
> https://codereview.appspot.com/87810048/diff/90001/go/gogo.h#newcode2220
> go/gogo.h:2220: // The backend representation for this object if it is a
> NAMED_OBJECT_TYPE.
> On 2014/04/17 15:29:53, iant wrote:
> > I think these can all move into the appropriate elements of u_. Put
> > backend_type_ in Named_type (actually I think it is already there anyhow),
put
> > backend_const_ in Named_constant, put backend_function_ in Function (that
one
> is
> > already there also).
>
> Done.
New diff to gcc/go/go-gcc.cc (linked from the playground to avoid going over the
message character limit)
http://play.golang.org/p/pfuPVlOM_d
On 2014/04/25 04:11:07, iant wrote: > I'm nervous about to change to Gcc_backend::immutable_struct to change ...
9 years, 12 months ago
(2014-04-25 22:37:13 UTC)
#12
On 2014/04/25 04:11:07, iant wrote:
> I'm nervous about to change to Gcc_backend::immutable_struct to change the
value
> of TREE_READONLY and TREE_CONSTANT between Gcc_backend::immutable_struct and
> Gcc_backend::immutable_struct_set_init. There have been cases in the recent
> past where changing flags led to trouble. See the long comment about the
> setting of DECL_WEAK in Gcc_backend::immutable_struct.
>
Agreed. I restored the original immutable_struct logic and instead added
Backend::gc_root_variable since I think this is a special enough case.
Diff of gcc/go/go-gcc.cc: http://play.golang.org/p/9F1zMfnHfV
*** Submitted as https://code.google.com/p/gofrontend/source/detail?r=e403fdfd3005 *** compiler: Use backend interface for defining global declarations. R=iant CC=gofrontend-dev ...
9 years, 12 months ago
(2014-04-26 03:33:04 UTC)
#14
Issue 87810048: code review 87810048: compiler: Use backend interface for defining global dec...
(Closed)
Created 10 years ago by cmang
Modified 9 years, 11 months ago
Reviewers:
Base URL:
Comments: 28