Nios2 arch=r1/r2
Hi, I'm looking at gcc-nios2 options -march. It seems two instruction sets can be selected (r1/r2) but I cannot find out where theses instructions set are described. On the other end I found this document https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/nios2/n2cpu_nii51017.pdf which describes several updates of the instruction set (section Document Revision History) from 2004 to 2015. I'm looking for a recent gcc-nios2 compiler compatible pour nios2 version 6.1 (November 2006) i.e. without the 'jmpi' instruction. Do I have to modify the backend to add a -mno-jmpi option ? Regards, Selim
Re: Compiler support for erasure of sensitive data
We are developing this feature for x86_64 I want to see which registers are being used by the current function for returning a value or as arguments. I traverse the rtl looking for clobbered registers, but I don't know how to find which registers are arguments from the current function and which are used for storing the return value. How do you suggest to do this? Thanks 2016-03-04 9:23 GMT-03:00 Segher Boessenkool : > On Tue, Mar 01, 2016 at 10:27:00AM +0100, Richard Biener wrote: >> > We were thinking on making a function attribute that ensures that non >> > necessary registers, or stack frames used by the function will be >> > correctly cleared before returning. >> > We think in implementing for x86_64 as a first work. >> > For this we are trying to modify the epilogue generation. Here we should >> > have the information of which registers this function used, and the size >> > of the stack frame to clean. The downside of this is that will be >> > architecture dependent. >> > Do you think this is a good idea? Do you suggest something else? >> >> I think you can't avoid doing architecture specific changes here. >> Note that on x86_64 you probably want to force >> -maccumulate-outgoing-args >> to avoid the use of push/pop and have the stack frame freeing fully in >> the epilogue. > > You'll also need to disable shrink-wrapping for that function. > > > Segher
Re: [gimplefe] [gsoc16] Gimple Front End Project
On 03/07/2016 11:33 AM, David Malcolm wrote: So for testing specific passes, I'd much rather have an input format for testing individual passes that: * can be easily generated by GCC from real test cases * ability to turn into unit tests, which implies: * human-readable and editable * compatibility and stability: can load gcc 7 test cases into gcc 8; have e.g. gcc 6 generate test cases * roundtrippable: can load the format, then save out the IR, and get the same file, for at least some subset of the format (consider e.g. location data: explicit location data can be roundtripped, implicit location data not so much). ...which suggests that we'd want to use gimple dumps as the input format to a test framework - which leads naturally to the idea of a gimple frontend. We already read and write gimple IL in LTO, we just do it in binary form. I think the kind of effort you are talking about here is best placed in attaching a gimple parser to LTO, thus giving LTO the ability to read and write textual gimple as well as the current binary form. The current dump format could in theory be a starting point, but its clearly missing hunks of stuff. there is probably a better representation. LTO already knows all the bits required to reconstruct gimple. The definition of the textual representation can make intelligent choices about defaults so that you don't have to specify every single bit in the textual form that the binary form requires. ThIs seems far easier to me than starting with the incomplete form that the current dumps generate and trying to discover what other bits need to be added to properly reconstruct the IL. I think its hard to get a lot of the subtle things right.I also think the scope of defining and reading/writing should be relatively manageable. We can optimize the details once its working. It would also be very useful then to have LTO enhanced so that it can read and write before or after any pass... Then we can unit test any pass by injecting the IL immediately before the pass.. No jumping through any hoops to make sure the pass you care about sees the exact IL you want.. That is also a good proof that the LTO form (both binary and text) does fully represent gimple. We can also use this output as our debugging dumps and archive the current dumper. As gimple changes and evolves the result is only one place to worry about for reading and writing... and as we progress (slowly) towards uncoupling the middle/backend from the front ends, we'd have a single well defined "front end" for gimple that accepts binary or text. Andrew
Re: [gimplefe] [gsoc16] Gimple Front End Project
On Wed, Mar 9, 2016 at 3:27 PM, Andrew MacLeod wrote:
> On 03/07/2016 11:33 AM, David Malcolm wrote:
>>>
>>>
>>>
>>>
>>>
>>> So for testing specific passes, I'd much rather have an input format
>>> for testing individual passes that:
>>>* can be easily generated by GCC from real test cases
>>>* ability to turn into unit tests, which implies:
>>> * human-readable and editable
>>>* compatibility and stability: can load gcc 7 test cases into gcc 8;
>>> have e.g. gcc 6 generate test cases
>>>* roundtrippable: can load the format, then save out the IR, and get
>>> the same file, for at least some subset of the format (consider e.g.
>>> location data: explicit location data can be roundtripped, implicit
>>> location data not so much).
>>>
>>> ...which suggests that we'd want to use gimple dumps as the input
>>> format to a test framework - which leads naturally to the idea of a
>>> gimple frontend.
>
>
>
> We already read and write gimple IL in LTO, we just do it in binary form. I
> think the kind of effort you are talking about here is best placed in
> attaching a gimple parser to LTO, thus giving LTO the ability to read and
> write textual gimple as well as the current binary form. The current
> dump format could in theory be a starting point, but its clearly missing
> hunks of stuff. there is probably a better representation.
>
> LTO already knows all the bits required to reconstruct gimple. The
> definition of the textual representation can make intelligent choices about
> defaults so that you don't have to specify every single bit in the textual
> form that the binary form requires. ThIs seems far easier to me than
> starting with the incomplete form that the current dumps generate and trying
> to discover what other bits need to be added to properly reconstruct the IL.
> I think its hard to get a lot of the subtle things right.I also think
> the scope of defining and reading/writing should be relatively manageable.
> We can optimize the details once its working.
>
> It would also be very useful then to have LTO enhanced so that it can read
> and write before or after any pass... Then we can unit test any pass by
> injecting the IL immediately before the pass.. No jumping through any hoops
> to make sure the pass you care about sees the exact IL you want.. That is
> also a good proof that the LTO form (both binary and text) does fully
> represent gimple. We can also use this output as our debugging dumps and
> archive the current dumper.
>
> As gimple changes and evolves the result is only one place to worry about
> for reading and writing... and as we progress (slowly) towards uncoupling
> the middle/backend from the front ends, we'd have a single well defined
> "front end" for gimple that accepts binary or text.
So I chose to reply to this one (and will refrain from replying to other but try
to address comments there).
First, while the LTO approach works it's quite overkill in the details
it "dumps"
and thus it's too closely tied to our internal bits which means testcases will
bitrot too quickly for the number one goal of having human
maintainable testcases.
It's nice if there's going to be somebody spending quite some of his
work-time towards
unit-testing (hope not specifically "the GIMPLE frontend").
In my view the C frontend already can target most of the middle-end features and
for those it can't it should be straight-forward to add GNU extensions
for. A critical
piece is of course SSA here, specifically PHIs. I think a reasonable way to
express those in C are to use labels:
int i;
if (...)
{
L1:
i_1 = 2;
}
else
{
L2:;
}
i_3 = __PHI (L1:i_1, L2:i);
so the testcases would be valid GNU C (not C). What would be missing for
unit-testing would be some "raw" mode to avoid having the C FE fold things
or apply type promotions (so you can actually write a signed short addition).
As of restricting statements to GIMPLE I think that's not necessary - I'd simply
run the GENERIC from the FE through the gimplifier (I have patches that deal
with SSA pre into-SSA just fine, at least for non-PHIs, and if all the
__PHI above
could be just an internal function pre "real" SSA).
Note that I don't think we should restrict ourselves by connecting what LTO does
with what the requirements for unit testing are. The convenient bit of
extending the C FE here is that dumping a function body in the required form
is going to be easy and that you can have a testcase harness in plain C while
feeding in a unit-test function as "GNU C GIMPLE" (or how you'll call it). Say,
extern void abort (void);
int x;
int __attribute__((GIMPLE)) foo ()
{
int _1;
_1 = x;
return _1;
}
int main()
{
if (foo () != 1)
abort ();
return 0;
}
and the above would extend to __attribute__((RTL)) if anybody wants to
introduce that.
Give 'GIMPLE' an argument like __attribute__((GIMPLE("tree-pre"))) to
specify the
place to inject the function [you still have to feed it to the cgraph
from
Re: [gimplefe] [gsoc16] Gimple Front End Project
On Wed, Mar 9, 2016 at 10:47 AM, Richard Biener wrote: > About using the LLVM IR - similar issue I think, plus it is probably > too far away > from GCC so that what we'll end up will only look like LLVM IR but not > actually > be LLVM IR. I don't think this is feasible at all, actually. As I said in my message, LLVM IR and GIMPLE are fairly different in terms of abstraction. The main goal is providing a text-based representation for GIMPLE that can be used as input into any arbitrary stage of the optimizer. This also implies other modularization efforts that allow this. Whether or not GIMPLE looks like C, or this is done piggybacking the C FE, is a different issue. I think the first issue to solve is defining GIMPLE as a full, compilable language with well formed execution and data semantics. Diego.
Re: [gimplefe] [gsoc16] Gimple Front End Project
On Wed, Mar 9, 2016 at 5:07 PM, Diego Novillo wrote: > On Wed, Mar 9, 2016 at 10:47 AM, Richard Biener > wrote: > >> About using the LLVM IR - similar issue I think, plus it is probably >> too far away >> from GCC so that what we'll end up will only look like LLVM IR but not >> actually >> be LLVM IR. > > I don't think this is feasible at all, actually. As I said in my > message, LLVM IR and GIMPLE are fairly different in terms of > abstraction. > > The main goal is providing a text-based representation for GIMPLE that > can be used as input into any arbitrary stage of the optimizer. This > also implies other modularization efforts that allow this. > > Whether or not GIMPLE looks like C, or this is done piggybacking the C > FE, is a different issue. I think the first issue to solve is > defining GIMPLE as a full, compilable language with well formed > execution and data semantics. I don't think that's necessary. GIMPLE is an implementation detail and it should remain that. For unit testing it's only required to be able to input sth resembling GIMPLE close enough. All is necessary is to define execution and data semantics of the C extensions we need to get "close enough". After all GIMPLEs execution and data semantics are basically Cs (with some extras not covered by C). Richard. > > Diego.
Re: [gimplefe] [gsoc16] Gimple Front End Project
On 03/09/2016 10:47 AM, Richard Biener wrote: On Wed, Mar 9, 2016 at 3:27 PM, Andrew MacLeod wrote: On 03/07/2016 11:33 AM, David Malcolm wrote: So for testing specific passes, I'd much rather have an input format for testing individual passes that: * can be easily generated by GCC from real test cases * ability to turn into unit tests, which implies: * human-readable and editable * compatibility and stability: can load gcc 7 test cases into gcc 8; have e.g. gcc 6 generate test cases * roundtrippable: can load the format, then save out the IR, and get the same file, for at least some subset of the format (consider e.g. location data: explicit location data can be roundtripped, implicit location data not so much). ...which suggests that we'd want to use gimple dumps as the input format to a test framework - which leads naturally to the idea of a gimple frontend. We already read and write gimple IL in LTO, we just do it in binary form. I think the kind of effort you are talking about here is best placed in attaching a gimple parser to LTO, thus giving LTO the ability to read and write textual gimple as well as the current binary form. The current dump format could in theory be a starting point, but its clearly missing hunks of stuff. there is probably a better representation. LTO already knows all the bits required to reconstruct gimple. The definition of the textual representation can make intelligent choices about defaults so that you don't have to specify every single bit in the textual form that the binary form requires. ThIs seems far easier to me than starting with the incomplete form that the current dumps generate and trying to discover what other bits need to be added to properly reconstruct the IL. I think its hard to get a lot of the subtle things right.I also think the scope of defining and reading/writing should be relatively manageable. We can optimize the details once its working. It would also be very useful then to have LTO enhanced so that it can read and write before or after any pass... Then we can unit test any pass by injecting the IL immediately before the pass.. No jumping through any hoops to make sure the pass you care about sees the exact IL you want.. That is also a good proof that the LTO form (both binary and text) does fully represent gimple. We can also use this output as our debugging dumps and archive the current dumper. As gimple changes and evolves the result is only one place to worry about for reading and writing... and as we progress (slowly) towards uncoupling the middle/backend from the front ends, we'd have a single well defined "front end" for gimple that accepts binary or text. So I chose to reply to this one (and will refrain from replying to other but try to address comments there). First, while the LTO approach works it's quite overkill in the details it "dumps" and thus it's too closely tied to our internal bits which means testcases will bitrot too quickly for the number one goal of having human maintainable testcases. The binary form is clearly tied to a lot of implementation bits, but I would think a lot of those bits have a reasonable default value that wouldn't have to be explicitly expressed in textual form, but could be if so desired via attributes, tags, new keywords, or whatever. The current dumps are C-like and could work as a decent starting point for textual gimple input/output. From the LTO vantage point, you can see all the other bits which might need to be expressed, and can get to them later. That is "merely" the follow on hard work of flushing out the details :-) I'd just hate to see a lot of work go into it and have it made completely redundant in a few years by the presence of a new lto reader/writer than can do the same job. Of course that's still blue-sky stuff and could never happen. No matter what approach is taken, it would be good to keep in mind the possibility of enhancing it to be the LTO text reader so that decisions aren't made which make that impractical..I don't think its on my hit list for a while yet... but it would be really nice to be able to leverage any work that is done in this direction. It would be ideal to be able to simply add enhancements to whatever we have to provide the rest of what LTO requires to be a complete reader/writer. Andrew
Re: Implementing TI mode (128-bit) and the 2nd pipeline for the MIPS R5900
On 03/09/2016 08:45 AM, Woon yung Liu wrote: 3. due to the current register size (UNITS_PER_WORD) definition, allocating a TI mode register will cause two consecutive registers to be allocated instead (like the HILO pseudo register) of one (other than just being wrong, it is probably wasteful). Due to number 3, that also means that I cannot actually properly implement support for any vector mode because they're all 128-bit vectors. :( Why do you believe that not using TImode precludes you implementing any vector support? I don't think you need to touch TImode at all. Just implement V16QImode, V8HImode and maybe V4SImode. These modes can be special cased within mips_hard_regno_nregs and mips_class_max_nregs to only consume one register. The LQ/SQ instructions, if not used with the other MMI instructions, could also be used to speed up memory copying. But they operate on the full 128-bit GPRs, and are hence unusable without a 128-bit mode. But you'll have at least one 128-bit mode (and maybe 3). The memcpy expander will simply have to be taught to use them. r~
Re: Compiler support for erasure of sensitive data
[ Please don't top-post. ] On Wed, Mar 09, 2016 at 11:23:22AM -0300, Andres Tiraboschi wrote: > We are developing this feature for x86_64 > I want to see which registers are being used by the current function > for returning a value or as arguments. > I traverse the rtl looking for clobbered registers, but I don't know > how to find which registers are arguments from the current function > and which are used for storing the return value. How do you suggest to > do this? You can probably do something with diddle_return_value. Segher
Re: [gimplefe] [gsoc16] Gimple Front End Project
On 9 March 2016 at 02:50, Trevor Saunders wrote: > On Tue, Mar 08, 2016 at 05:12:56PM -0500, Diego Novillo wrote: >> This way, implementing a library that supports dealing with GIMPLE >> becomes much simpler. This provides a nice foundation for all kinds >> of gimple-oriented tooling in the future. > > Well, one nice thing about choosing a subset of C as your textual > representation of gimple is that all the tools that deal with C already > can deal with it, and so you won't really need separate tools for gimple > (that would be my theory anyway). What tools available for C would be useful for working with gimple IR? Diego means tools like those available for modifying, compiling and verifying LLVM IR and its bytecode representation. Things like http://www.cis.upenn.edu/~stevez/vellvm/ and http://blog.regehr.org/archives/1170 No such thing is available for C (nor GIMPLE), because they are not a well-defined IR (http://lambda-the-ultimate.org/node/715#comment-6526). If the gimple IR were a strict subset of GNU C, then by all means let's re-use the C FE. However, gimple encodes things that are necessary for other languages but are not C. C++ gimple dumps have try-finally. Fortran dumps use explicit parentheses "((x))". Surely, Ada adds its own quirks to gimple. You can probably represent all this with a C-looking language plus some large number of new __builtins_ and __attributes__. At that point you will end up with something that is neither a super-set, nor a sub-set of any of the many C variants already supported by the C parser. Thus, one would need to significantly hack the existing C parser to correctly parse this C-looking language, while not breaking any of the things supported by the C parser, nor accepting anything not supported by gnu/std C. Should the gimple-C parser support promotion rules? If GIMPLE is three-adresses-based, why support expressions with more than two operands at all? If the dumped IR should be sufficient to stop compilation, dump, reload, and continue, then how to represent language-specific tree codes that survive until RTL? (perhaps FE trees leaking into RTL got fixed already and I'm outdated here). What about preserving the original source locations? And debug info? All that would need to be handled by a gcc equivalent of LLVM's opt tool. How is all that going to be represented in gimple-C? Cheers, Manuel.
Re: Nios2 arch=r1/r2
On 03/09/2016 03:03 AM, BELBACHIR Selim wrote: Hi, I'm looking at gcc-nios2 options -march. It seems two instruction sets can be selected (r1/r2) but I cannot find out where theses instructions set are described. On the other end I found this document https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/nios2/n2cpu_nii51017.pdf which describes several updates of the instruction set (section Document Revision History) from 2004 to 2015. I'm looking for a recent gcc-nios2 compiler compatible pour nios2 version 6.1 (November 2006) i.e. without the 'jmpi' instruction. Do I have to modify the backend to add a -mno-jmpi option ? GCC does not support such old versions of the Nios II instruction set as you want. I suppose adding a -mno-jmpi option would be the best way to handle it. -march= is something else entirely, to support new revisions of the architecture rather than old ones. -Sandra
Re: [gimplefe] [gsoc16] Gimple Front End Project
> If the gimple IR were a strict subset of GNU C, then by all means > let's re-use the C FE. However, gimple encodes things that are > necessary for other languages but are not C. C++ gimple dumps have > try-finally. Fortran dumps use explicit parentheses "((x))". Surely, > Ada adds its own quirks to gimple. No, it doesn't, only to GENERIC, i.e. everything is lowered in GIMPLE and as far as I know there are no Ada-specific constructs in GIMPLE, so you can take Ada completely out of the picture here. -- Eric Botcazou
gcc-4.9-20160309 is now available
Snapshot gcc-4.9-20160309 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160309/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 234093 You'll find: gcc-4.9-20160309.tar.bz2 Complete GCC MD5=e90142ae80a59df2580703b5bb217d04 SHA1=318a3e1e4e24266ca04de278981577aaa911ae23 Diffs from 4.9-20160302 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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: [gimplefe] [gsoc16] Gimple Front End Project
On Wed, Mar 09, 2016 at 07:45:57PM +, Manuel López-Ibáñez wrote: > On 9 March 2016 at 02:50, Trevor Saunders wrote: > > On Tue, Mar 08, 2016 at 05:12:56PM -0500, Diego Novillo wrote: > >> This way, implementing a library that supports dealing with GIMPLE > >> becomes much simpler. This provides a nice foundation for all kinds > >> of gimple-oriented tooling in the future. > > > > Well, one nice thing about choosing a subset of C as your textual > > representation of gimple is that all the tools that deal with C already > > can deal with it, and so you won't really need separate tools for gimple > > (that would be my theory anyway). > > What tools available for C would be useful for working with gimple IR? for one thing other compilers can deal with it, that is you can take the output of a pass and feed it to clang (I'm not totally sure if you could make phis work somehow, but suspect it might be possible). > Diego means tools like those available for modifying, compiling and > verifying LLVM IR and its bytecode representation. Things like > http://www.cis.upenn.edu/~stevez/vellvm/ and So, if your IR is C you can use clang to turn it into llvm IR, or run any C static checker you like on it. > http://blog.regehr.org/archives/1170 No such thing is available for C > (nor GIMPLE), because they are not a well-defined IR Well, C certainly is a well defined language, and I don't see a reason you can't modify that tool to work with it as easily as you could for any other IR than LLVM's. > (http://lambda-the-ultimate.org/node/715#comment-6526). > > If the gimple IR were a strict subset of GNU C, then by all means > let's re-use the C FE. However, gimple encodes things that are > necessary for other languages but are not C. C++ gimple dumps have > try-finally. Fortran dumps use explicit parentheses "((x))". Surely, > Ada adds its own quirks to gimple. You can probably represent all this eh is lowered to something without try / finally pretty early so that doesn't seem like a big deal, and I can see very little evidence for PAREN_EXPR effecting optimization so its not clear to me that is an issue either. > with a C-looking language plus some large number of new __builtins_ > and __attributes__. At that point you will end up with something that > is neither a super-set, nor a sub-set of any of the many C variants > already supported by the C parser. Thus, one would need to > significantly hack the existing C parser to correctly parse this > C-looking language, while not breaking any of the things supported by > the C parser, nor accepting anything not supported by gnu/std C. I may be wrong, and I'm kind of tempted to prototype something stand alone just using bison and flex, but I suspect there won't be *that* many changes especially if you use your own statement parser, and the changes you would make would mostly be of the form if we are in gimple mode this construct isn't legal. > Should the gimple-C parser support promotion rules? If GIMPLE is I'm not really a gimple expert, but I would tend to say no. > three-adresses-based, why support expressions with more than two Well, you might not, or you could decide it is just easier to support it than not (and that could be handy for writing test cases). > operands at all? If the dumped IR should be sufficient to stop > compilation, dump, reload, and continue, then how to represent > language-specific tree codes that survive until RTL? (perhaps FE trees I'm under the impression that is mostly only for debug info? and anyway that's a problem lto has already dealt with. > leaking into RTL got fixed already and I'm outdated here). What about > preserving the original source locations? And debug info? All that if your goal is only unit testing then I think you can just not care about these, or at least they aren't very important. Trev > would need to be handled by a gcc equivalent of LLVM's opt tool. How > is all that going to be represented in gimple-C? > > Cheers, > > Manuel.
