Re: global declarations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17 September 2010 15:24, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
> Philip Herron <redbrain@xxxxxxxxxxx> writes:
>
>> On 17 September 2010 06:38, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
>>> Philip Herron <redbrain@xxxxxxxxxxx> writes:
>>>
>>>> Been asking on irc tonight but i think many might be sensible and
>>>> sleeping. Anyway's this has been bugging me for some time, if i create
>>>> a VAR_DECL such as:
>>>>
>>>> tree test = build_decl( UNKNOWN_LOCATION, VAR_DECL,
>>>>                         get_identifier("test"),
>>>>                         integer_type_node);
>>>>
>>>>   TREE_CONSTANT (test) = 1;
>>>>   DECL_ARTIFICIAL (test) = 1;
>>>>   TREE_STATIC (test) = 1;
>>>>   TREE_READONLY (test) = 1;
>>>>   TREE_USED (test) = 1;
>>>>   DECL_INITIAL (test) = build_int_cst(integer_type_node, 1234 );
>>>
>>> By setting TREE_CONSTANT and TREE_STATIC, you are marking this decl as a
>>> static const, more or less like a C++ const.  It will only be written
>>> out if something else refers to it.  You probably don't want to set
>>> TREE_CONSTANT.
>>>
>>
>> I just tried that and played with and added in extras to see if they
>> help and it still didn't output any code.
>>
>>    tree test = build_decl( UNKNOWN_LOCATION, VAR_DECL,
>>                         get_identifier("test"),
>>                         integer_type_node);
>>
>>   DECL_ARTIFICIAL (test) = 1;
>>   TREE_PUBLIC(test) = 1;
>>   TREE_USED (test) = 1;
>>   DECL_INITIAL (test) = build_int_cst(integer_type_node, 12345 );
>
> But now you don't have TREE_STATIC.
>
>> I am trying to follow what the c front-end is doing but
>> gimplify_expression isn't called on a toplevel global VAR_DECL, since
>> i wanted to see the debug_tree of the decl, though code is still
>> output for it. I might be able to run though its write-globals
>> function and call debug_tree there to see the difference.
>
> Certainly you can always call rest_of_decl_compilation, but the question
> is why that isn't happening for your case when you call
> wrapup_global_declarations.
>

Thanks! With TREE_STATIC it works now, but i need
rest_of_decl_compilation (test, 1, 0); to be called or code won't be
generated. I've been tempted to look into a new interface to the
middle-end, but i don't really think i have the experience with
generic/gimple and the middle-end to do so..... yet ;) .

It seems it would be nice if we could simply have a function to pass a
VEC(tree,gc) * of your decls instead of calling each of these awkward
functions:

  wrapup_global_declarations( global_vec, global_vec_len );

  check_global_declarations( global_vec, global_vec_len );
  emit_debug_global_declarations( global_vec, global_vec_len );

  cgraph_finalize_compilation_unit( );

While putting all your decls into a tree* . And for it to call
gimpligy_function_tree and rest_of_decl_compliation's etc. And i think
the write_globals lang_hook is a little cryptic since this is the one
where we pass things over to the middle end shouldn't it be something
like lang_hook_write_to_middle_end (void) ?

I know many/all front-end hackers like me don't like calling
cgraph_finalize_compilation_unit (); but i am not sure how this
affects compiling multiple files in one instance, do we sitll call
this after each file and start clean that makes sense to me but maybe
its not. Would it be sensible to to move this to just after the
lang_hooks.write_globals () is called in do_compile () ?

I think this is just a little dump of my brain sorry for lots of
possiibly related questions. :)

--Phil



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux