Re: Zero/Sign extension elimination using value ranges
On Wed, May 21, 2014 at 12:53:47PM +1000, Kugan wrote: > On 20/05/14 16:52, Jakub Jelinek wrote: > > On Tue, May 20, 2014 at 12:27:31PM +1000, Kugan wrote: > >> 1. Handling NOP_EXPR or CONVERT_EXPR that are in the IL because they > >> are required for type correctness. We have two cases here: > >> > >> A) Mode is smaller than word_mode. This is usually from where the > >> zero/sign extensions are showing up in final assembly. > >> For example : > >> int = (int) short > >> which usually expands to > >> (set (reg:SI ) > >> (sext:SI (subreg:HI (reg:SI > >> We can expand this > >> (set (reg:SI ) (((reg:SI > >> > >> If following is true: > >> 1. Value stored in RHS and LHS are of the same signedness > >> 2. Type can hold the value. i.e., In cases like char = (char) short, we > >> check that the value in short is representable char type. (i.e. look at > >> the value range in RHS SSA_NAME and see if that can be represented in > >> types of LHS without overflowing) > >> > >> Subreg here is not a paradoxical subreg. We are removing the subreg and > >> zero/sign extend here. > >> > >> I am assuming here that QI/HI registers are represented in SImode > >> (basically word_mode) with zero/sign extend is used as in > >> (zero_extend:SI (subreg:HI (reg:SI 117)). > > > > Wouldn't it be better to just set proper flags on the SUBREG based on value > > range info (SUBREG_PROMOTED_VAR_P and SUBREG_PROMOTED_UNSIGNED_P)? > > Then not only the optimizers could eliminate in zext/sext when possible, but > > all other optimizations could benefit from that. > > Thanks for the comments. Here is an attempt (attached) that sets > SUBREG_PROMOTED_VAR_P based on value range into. Is this the good place > to do this ? But you aren't setting it in your patch in any way, you are just resetting it instead. The thing is, start with a testcase where you get that (subreg:HI (reg:SI)) as the RTL of some SSA_NAME (is that the case on ARM?, I believe on e.g. i?86/x86_64 you'd just get (reg:HI) instead and thus you can't take advantage of that), and at that point where it is created check the range info and if it is properly sign or zero extended, set SUBREG_PROMOTED_VAR_P and SUBREG_PROMOTED_UNSIGNED_SET. Note that right now we use 2 bits for the latter, which encode values -1 (weirdo pointer extension), 0 (sign extension), 1 (zero extension). Perhaps it would be nice to allow encoding value 2 (zero and sign extension) for cases where the range info tells you that the value is both zero and sign extended (i.e. minimum of range is >= 0 and maximum is <= signed type maximum). Jakub
Re: soft-fp functions support without using libgcc
On Tue, May 20, 2014 at 10:47 PM, Ian Lance Taylor wrote: > On Tue, May 20, 2014 at 12:51 PM, Sheheryar Zahoor Qazi > wrote: >> Hi again! >> You need to look in target-arch/libgcc/config.log to see what the problem is. >> config.log states the following error: >> configure:2590: checking for suffix of object files >> configure:2611: /home/lab/target/target-gcc/builddir/./gcc/xgcc >> -B/home/lab/target/target-gcc/builddir/./gcc/ -B/usr/local/target/bin/ >> -B/usr/local/target/lib/ -isystem /usr/local/target/include -isystem >> /usr/local/target/sys-include -c -g -O2conftest.c >&5 >> /home/laboruser/spartanmc/spartanmc-gcc/builddir/./gcc/as: 76: exec: : >> Permission denied >> configure:2614: $? = 1 >> configure: failed program was: >> | /* confdefs.h. */ >> >> Is it complaining for root access?? > > > Please reply to the mailing list, not just to me. Thanks. > > I doubt it is a root access issue. Look at the permissions of the > gcc/as file. You will probably need to debug it a bit to find out why > it is failing. It's just a shell script so it shouldn't be too hard. > > It's because libgcc was not built. >> What are my options to provide software floating point support to my >> architecture if I am unable to build libgcc for my target? >> Any example implementation?? > > Building libgcc is not optional. It is required for all targets. > > Ian
Re: Roadmap for 4.9.1, 4.10.0 and onwards?
Am 05/20/2014 06:04 PM, schrieb Paulo Matos: From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Basile Starynkevitch Sent: 20 May 2014 16:29 To: Bruce Adams Cc: gcc@gcc.gnu.org Subject: Re: Roadmap for 4.9.1, 4.10.0 and onwards? On Tue, 2014-05-20 at 11:09 +0100, Bruce Adams wrote: Hi, I've been tracking the latest releases of gcc since 4.7 or so (variously interested in C++1y support, cilk and openmp). One thing I've found hard to locate is information about planned inclusions for future releases. As much relies on unpredictable community contributions I don't expect there to be a concrete or reliable plan. However, equally I'm sure the steering committee have some ideas over what ought to be upcoming releases. As a whole, the steering committee does not have any idea, because GCC development is based upon volunteer contributions. I understand the argument but I am not sure it's the way to go. Even if the project is based on volunteer contributions it would be interesting to have a tentative roadmap. This, I would think, would also help possible beginner volunteers know where to start if they wanted to contribute to the project. So the roadmap could be a list of features (big or small) of bug fixes that we would like fixed for a particular version. Even if we don't want to name it roadmap it would still be interesting to have a list of things that are being worked on or on the process of being merged into mainline and therefore will make it to the next major version. That being said I know it's hard to set sometime apart to write this kind of thing given most of us prefer to be hacking on GCC. From a newcomer point of view, however, not having things like a roadmap makes it look like the project is heading nowhere. Isn't https://gcc.gnu.org/projects/ supposed to be such a page? (linked from the front page). And in particular its "projects for beginner GCC hackers" link? Or is it complete doc-rot? Johann
Re: RFC: Doc update for attribute
Am 05/20/2014 03:31 PM, schrieb Carlos O'Donell: On 05/20/2014 03:59 AM, Georg-Johann Lay wrote: Am 05/16/2014 07:16 PM, schrieb Carlos O'Donell: On 05/12/2014 11:13 PM, David Wohlferd wrote: After updating gcc's docs about inline asm, I'm trying to improve some of the related sections. One that I feel has problems with clarity is __attribute__ naked. I have attached my proposed update. Comments/corrections are welcome. In a related question: To better understand how this attribute is used, I looked at the Linux kernel. While the existing docs say "only ... asm statements that do not have operands" can safely be used, Linux routinely uses asm WITH operands. That's a bug. Period. You must not use naked with an asm that has operands. Any kind of operand might inadvertently cause the compiler to generate code and that would violate the requirements of the attribute and potentially generate an ICE. There is target hook TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS that is intended to cater that case. For example, the documentation indicates it only works with optimization turned off. But I don't know how reliable it is in general. For avr target it works as expected. https://gcc.gnu.org/onlinedocs/gccint/Misc.html#index-TARGET_005fALLOCATE_005fSTACK_005fSLOTS_005fFOR_005fARGS-4969 It's still a bug for now. That hook is there because we've allowed bad code to exist for so long that at this point we must for legacy reasons allow some type of input arguments in the asm. However, that doesn't mean we should actively promote this feature or let users use it (until we fix it). Ideally you do want to use the named input arguments as "r" types to avoid needing to know the exact registers used in the call sequence. It won't work to let the compiler pick the used registers. Referencing the variables by name and letting gcc emit the right register is useful, but only if it works consistently and today it doesn't. In order to use the passed arguments, you must know the ABI and how / where the arguments are passed. Then the asm template can use this information explicitly, but the asm itself still has no arguments. The hook mentioned above is to avoid extra code besides (non-existing) pro/epilogue and the asm itself. So that naked function with arguments and asm without arguments work at any optimization level. Features that fail to work depending on the optimization level should not be promoted in the documentation. We should document what works and file bugs or fix what doesn't work. Cheers, Carlos.
Re: soft-fp functions support without using libgcc
>>Building libgcc is not optional. It is required for all targets. So, irrespective whether i provide floating point implementation by soft-fp, fpu-bit or ieeelib, an error free libgcc build is a MUST? What if I dont want to generate calls to libgcc.a but want want gcc to generate inline code? Regards Sheheryar
Re: soft-fp functions support without using libgcc
On Wed, May 21, 2014 at 6:13 AM, Sheheryar Zahoor Qazi wrote: >>>Building libgcc is not optional. It is required for all targets. > > So, irrespective whether i provide floating point implementation by > soft-fp, fpu-bit or ieeelib, an error free libgcc build is a MUST? Yes. > What if I dont want to generate calls to libgcc.a but want want gcc to > generate inline code? libgcc also provides functionality that GCC requires that can not reasonably be inlined, such as the stack unwind code used for exception handling. Ian
Re: Weird startup issue with -fsplit-stack
On Tue, May 20, 2014 at 10:30 PM, Dmitry Antipov wrote:
>
> The next major problem is that -fsplit-stack code randomly crashes with the
> useless gdb backtrace, usually pointing to the very beginning of the
> function
> (plus occasional "Cannot access memory at..." messages), e.g.:
>
> (gdb) bt 1
> #0 0x005a615b in mark_object (arg=0) at
> ../../trunk/src/alloc.c:6039
>
> 6037 void
> 6038 mark_object (Lisp_Object arg)
> ==> 6039 {
>
> IIUC this usually (with traditional stack) happens due to stack overflow.
> But what may be the case with -fsplit-stack? I do not receive any error
> messages from libgcc, and there are a lot of free heap memory. If that
> matters,
> mark_object is recursive, and recursion depth may be very high, up to a few
> tens of thousands calls.
I'm sorry, I have nothing useful to suggest. I agree that that sounds
like a stack overflow, which should in general be impossible with
-fsplit-stack when using the gold linker. I don't know what is
happening here. I've tested with massive recursion so I don't think
that is the problem by itself.
Ian
Re: negative latencies
On 2014-05-20, 5:18 PM, shmeel gutl wrote: On 20-May-14 06:13 PM, Vladimir Makarov wrote: On 05/19/2014 02:13 AM, shmeel gutl wrote: Are there hooks in gcc to deal with negative latencies? In other words, an architecture that permits an instruction to use a result from an instruction that will be issued later. Could you explain more on *an example* what are you trying to achieve with the negative latency. Scheduler is based on a critical path algorithm. Generally speaking latency time can be negative for this algorithm. But I guess that is not what you are asking. The architecture has an exposed pipeline where instructions read registers during the required cycle. So if one instruction produces its results in the third pipeline stage and a second instruction reads the register in the sixth pipeline stage, the second instruction can read the results of the first instruction even if it is issued three cycles earlier. The problem that I see is that the haifa scheduler schedules one cycle at a time, in a forward order, by picking from a list of instructions that can be scheduled without delays. So, in the above example, if instruction one is scheduled during cycle 3, it can't schedule instruction two during cycle 0, 1, or 2 because its producer dependency (instruction one) hasn't been scheduled yet. It won't be able to schedule it until cycle 3. So I am asking if there is an existing mechanism to back schedule instruction two once instruction one is issued. I see, thanks. There is no such mechanism in the current insn scheduler. A lot of things should be done to implement this. It is possible but it will be not easy, the insn scheduler is already quite complicated as it supports too many things. I am just curious what happens when you put insn2, insn1. and insn2 uses a result of insn1 in 6 cycles and insn1 producing the result in 3 cycles, but there are not ready functional units (e.g. arithmentic units) necessary for insn1 for 4 or more cycles. It is quite not trivial to guarantee that everything will be okay in general case if you put insn2 before insn1.
gcc-4.9-20140521 is now available
Snapshot gcc-4.9-20140521 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140521/ 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 210728 You'll find: gcc-4.9-20140521.tar.bz2 Complete GCC MD5=cd3cbe93ebc7207bf65d30e3c9a74a26 SHA1=3b785178557ca1ed338e4b8b1f605da6dcc386f7 Diffs from 4.9-20140514 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.
