Traversing trees in a plugin...
Hi all, I'm working on a GCC plugin, having made a lot of progress on that front. So far running my plugin works 'more or less' on things like the linux kernel. On the other hand running it on the plugin itself causes problems. Given that some of the data structures are pretty complicated in GCC I'm not surprised. So the question I have (w.r.t. TREE data structures) are: 1) How to marking a node as visited by my algorithm (without screwing up the compiler!) 2) How to associate additional data (perhaps a pointer to something else) to a node (like a unique identifier, or a pointer to a data structure). Thoughts: 1) The general overview of my current algorithm: a) When a node can be uniquely identified (has an identifier or position information) I can use a look up. b) However with types (especially those that are anonymous) I find it challenging to do so. I assign such a node an anonymous identifier or try to assign a general data type (i.e. integer) when the type is internal. c) When I arrive at a node and it is identifiable and it is found in the lookup table I can infer that its children have also been visited. d) However there may be cases when I cannot identify where a node has been visited, and processing is duplicated. e) This method seems quite inefficient, error prone. 2) Can memory addresses be used to uniquely identify nodes? I believe this may be the case for identifier nodes. 3) Other ideas? I tuned my process based on trial and error, and focused on what worked at the time. I think I'm doing it in the wrong way. Brett
Re: Fixincludes
On May 28, 2012, at 7:25 PM, Jonathan Wakely wrote: > The "upstream packages" might be a third-party OS vendor who supply > their own compiler and have no interest in supporting GCC. Even if the > OS system headers get changed, that doesn't help users who have the > unchanged version (e.g. someone wanting to build GCC on SOlaris 9 > isn't helped by a change in Solaris 11). New OS releases frequently > include changes that need to be worked around (e.g. FreeBSD recently > started using C++11 attributes in their system headers, which GCC > doesn't support yet.) OK, thanks for this reply. For a situation when the only available headers are the sanitized Linux headers and those from recent glibc (or some other modern libc) am I correct in assuming that this script is unnecessary and could, conceivably alter something that shouldn't be altered? Thanks, JH
Re: Traversing trees in a plugin...
On Sat, 2 Jun 2012 10:48:47 -0700
Brett Foster wrote:
> Hi all,
>
> I'm working on a GCC plugin, having made a lot of progress on that
> front. So far running my plugin works 'more or less' on things like
> the linux kernel. On the other hand running it on the plugin itself
> causes problems. Given that some of the data structures are pretty
> complicated in GCC I'm not surprised.
>
> So the question I have (w.r.t. TREE data structures) are:
>
> 1) How to marking a node as visited by my algorithm (without screwing
> up the compiler!)
>
> 2) How to associate additional data (perhaps a pointer to something
> else) to a node (like a unique identifier, or a pointer to a data
> structure).
In the MELT meta-plugin (recall that MELT is a high-level domain specific
language to
extend GCC, see http://gcc-melt.org/ for more) we extensively use associative
hash-tables
for that. MELT offers homogeneous hash-tables, e.g. hash-table associating tree
(i.e.
non-null tree pointers) to arbitrary non-null MELT values (e.g. MELT closures,
or MELT
lists, or MELT objects, etc etc), or hash-table associating (non null) gimple
to non
null MELT values.
So you can have e.g. an hash-table associating each tree (every tree is in GCC
a non-null
pointer to a structure) with data associated to it. Once it has some data you
know that
this tree has been visited.
You cannot (in current GCC architecture) extend existing GCC core data
representations.
For example, you cannot add a new field to the union tree_node or to the struct
tree_decl_common ... I recommend associating information in your own plugin data
structure, such as some hash table.
In a few words, plugins cannot extend existing GCC data structures, but can
associate them
to their own data.
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Traversing trees in a plugin...
On Sat, 2 Jun 2012 20:31:26 +0200
Basile Starynkevitch wrote:
> In a few words, plugins cannot extend existing GCC data structures, but can
> associate them
> to their own data.
I forgot to mention that gimple-s (but not tree-s) give you a unsigned client
number
called a uid, which a single pass can set with gimple_set_uid and retrieve with
gimple_uid, but that uid does not survive the end of a single pass (so you
cannot use it
to communicate data between two different passes of your plugin).
Regards
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Traversing trees in a plugin...
On Sat, Jun 2, 2012 at 11:31 AM, Basile Starynkevitch wrote: > In the MELT meta-plugin (recall that MELT is a high-level domain specific > language to > extend GCC, see http://gcc-melt.org/ for more) we extensively use associative > hash-tables > for that. MELT offers homogeneous hash-tables, e.g. hash-table associating > tree (i.e. > non-null tree pointers) to arbitrary non-null MELT values (e.g. MELT > closures, or MELT > lists, or MELT objects, etc etc), or hash-table associating (non null) gimple > to non > null MELT values. > > So you can have e.g. an hash-table associating each tree (every tree is in > GCC a non-null > pointer to a structure) with data associated to it. Once it has some data you > know that > this tree has been visited. I'll poke around the MELT source code - In Melt, where in source code may I have a look to see how trees and mapped to the hash table? Are you able to summarize the basics? I.e. the hash for a specific node tree is derived from what data? Pointer address? Thanks for the info.
Re: Traversing trees in a plugin...
On Sat, 2 Jun 2012 11:47:51 -0700
Brett Foster wrote:
> On Sat, Jun 2, 2012 at 11:31 AM, Basile Starynkevitch
> wrote:
> > In the MELT meta-plugin (recall that MELT is a high-level domain specific
> > language to
> > extend GCC, see http://gcc-melt.org/ for more) we extensively use
> > associative hash-tables
> > for that. MELT offers homogeneous hash-tables, e.g. hash-table associating
> > tree (i.e.
> > non-null tree pointers) to arbitrary non-null MELT values (e.g. MELT
> > closures, or MELT
> > lists, or MELT objects, etc etc), or hash-table associating (non null)
> > gimple to non
> > null MELT values.
> >
> > So you can have e.g. an hash-table associating each tree (every tree is in
> > GCC a non-null
> > pointer to a structure) with data associated to it. Once it has some data
> > you know that
> > this tree has been visited.
>
> I'll poke around the MELT source code -
>
> In Melt, where in source code may I have a look to see how trees and
> mapped to the hash table? Are you able to summarize the basics? I.e.
> the hash for a specific node tree is derived from what data? Pointer
> address?
MELT has a generic pointer (using the pointer address as hash function) to MELT
value hash
table. In its file melt-runtime.c which you can browse at
http://gcc.gnu.org/viewcvs/branches/melt-branch/gcc/melt-runtime.c
you can find near lines 3795-4020 functions like meltgc_raw_new_mappointers
meltgc_raw_put_mappointers melt_raw_get_mappointers ...
There are used from inline functions in gcc/melt-runtime.h &
gcc/melt/generated/meltrunsup.h ; allocated size of hash tables is a prime
number...
Feel free to ask more questions about that. (notice that MELT has a low-traffic
dedicated
list gcc-m...@googlegroups.com etc..)
Feel also free to download & try MELT!
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Fixincludes
> OK, thanks for this reply. For a situation when the only available > headers are the sanitized Linux headers and those from recent glibc > (or some other modern libc) am I correct in assuming that this script > is unnecessary and could, conceivably alter something that shouldn't > be altered? What are you after, exactly? Even on modern OSes, there might be glitches or small incompatibilities that woud need to be fixed in order for GCC to work properly, and fixincludes is the tried and proven tool to do that. It is designed to modify only what needs to be modified, but bugs cannot of course be ruled out like in any other piece of code. -- Eric Botcazou
gcc-4.7-20120602 is now available
Snapshot gcc-4.7-20120602 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120602/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 188142 You'll find: gcc-4.7-20120602.tar.bz2 Complete GCC MD5=d6d0c1d38f2e304cf1321778b75d2a36 SHA1=9af92a19920390fb4487372cb569bad4a2baa488 Diffs from 4.7-20120526 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Fixincludes
On 6/2/12 5:34 PM, Eric Botcazou wrote: What are you after, exactly? Even on modern OSes, there might be glitches or small incompatibilities that woud need to be fixed in order for GCC to work properly, and fixincludes is the tried and proven tool to do that. It is designed to modify only what needs to be modified, but bugs cannot of course be ruled out like in any other piece of code. There have been discussions about the need (or lack of) for this script to run on the Linux From Scratch development list. In LFS gcc is bootstrapped in a very confined chroot environment where the only headers available are the Linux headers and those from glibc. What is in question is whether it is better in our very minimal build environment to let the script run or disable it. Up until very recently it was disabled, in part because we wanted to ensure that nothing from the original host system leaked into the chroot system. But given that we have limited the ability of the host system to leak in via other means (i.e., sysroot and our 3 stage build) recently we removed the command that disabled it. After reading up further, it appears that the possibility exists that the script may 'fix' things in the libc headers that we don't want or need 'fixed'. I'm trying to ascertain what things the script in particular is 'fixing' and which way is more technically sound in our build scenario. Thanks again, JH
The Point
Lemmings, What is the point of putting such an immense list of fragments of the manual online? What if we loose out internet? Do you hate the thought of making one whole file containing the whole manual available because no one else does it that way? Are you lost in the world if you do not follow, however blindly, after the crowd? Im sure that was your motivation. Dont even dream of trying to validate this infantile error. Anti-Lemming
Re: Option -pthread in test suite with cross compilers
On Fri, 18 May 2012, Ralf Corsepius wrote: > On 05/18/2012 09:24 AM, Sebastian Huber wrote: > > Hi, > > > > if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11 > > target, then I get several unexpected errors due to: > > > > gcc/testsuite/gcc/gcc.log:xgcc: error: unrecognized command line option > > '-pthread' > > gcc/testsuite/g++/g++.log:g++: error: unrecognized command line option > > '-pthread' > > > > The -pthread option is not necessary in RTEMS for the pthread API. I > > don't think that a special case in the test suite is desirable, thus we > > should add a dummy -pthread option to the RTEMS target configurations. > > Is this possible? In which file do I have to look for this? > > I am not sure, but AFAICT, -pthread is Linux-specific. No, it's the canonical multi-os option to enable pthreads, as generic as it gets. brgds, H-P
Re: Option -pthread in test suite with cross compilers
On Fri, 18 May 2012, Joel Sherrill wrote: > I don't mind having -pthread be a noop but the leap > from a having a header file to having a specific gcc > option is a stretch IMO. Unless EVERY gcc target with > pthread support is required by gcc to have that option. > Is that the undocumented(?) intent? IMHO that would be nice. ISTR there was discussion here a *long* while ago in an attempt to universalize -pthread (*for systems where pthreads are implemented*), that unfortunately died. brgds, H-P
Re: Option -pthread in test suite with cross compilers
On Fri, 18 May 2012, Ian Lance Taylor wrote: > Joel Sherrill writes: > > > On 05/18/2012 08:27 AM, Ian Lance Taylor wrote: > >> Ralf Corsepius writes: > >> > >>> I am not sure, but AFAICT, -pthread is Linux-specific. > >> It's not properly documented, but -pthread works on a number of hosts, > >> including Solaris, Darwin, FreeBSD, NetBSD, OpenBSD, AIX. > > Ian.. Is it better to make it a noop for RTEMS or fix the test > > infrastructure that is turning it on where it doesn't exist? > > Sorry to be vague, but I think it depends on whether the tests are > meaningful on RTEMS. If dg-require-effective-target pthread_h lets a > test run, then I suppose I think the -pthread option ought to work. There's also the effective-target pthread... (Somewhat redundant, but FWIW it pre-dates the effective-target pthread_h.) Depending on how the affected maintainers stand on the "-pthread"-everywhere question, you might want to add that test-case constraint to the tests requiring and passing -pthread. brgds, H-P
How to avoid sign or zero extension
I'm writing some optimized functions for gcc-arm in a library that obuses
shorts. So the problem I have is that in extremely many places resutls of my
optimized functions are needlessly sign or zero extended. That is, gcc adds
UXTH or SXTH opcode.
For example, imagine if I use clz instructions (count leading zeros). Result of
the function will be positive number between 0 and 32. So, in places where
result of that clz functions is assigned to a short int it shouldn't
sign-extend the result.
I use inline asm, and it works with arm's armcc if I use short as a result of
inline asm expression:
static __inline short CLZ(int n)
{
short ret;
#ifdef __GNUC__
__asm__("clz %0, %1" : "=r"(ret) : "r"(n));
#else
__asm { clz ret, n; }
#endif
return ret;
}
//test function
short test_clz(int n)
{
return CLZ(n);
}
ARMCC generates this code:
test_clz:
CLZ r0,r0
BX lr
GCC generates this code:
test_clz:
clz r0, r0
sxth r0, r0<--- offending line.
bx lr
any way to make gcc not sign-extend results?
Thank you
