Re: ppc eabi float arguments
On Wed, Sep 23, 2015 at 07:09:43PM -0400, Michael Meissner wrote: > On Tue, Sep 22, 2015 at 01:43:55PM -0400, David Edelsohn wrote: > > On Tue, Sep 22, 2015 at 1:39 PM, Bernhard Schommer > > wrote: > > > Hi, > > > > > > if been working with the windriver Diab c compiler for 32bit ppc for and > > > encountered an incompatibly with the eabi version of the gcc 4.83. When > > > calling functions with more than 8 float arguments the gcc stores the 9th > > > float argument (and so on) as a float where as the diab compiler stores > > > the > > > argument as a double using 8 byte. > > > > > > I checked the EABI document and it seems to support the way the diab > > > compiler passes the arguments: > > > > > > "Arguments not otherwise handled above [i.e. not passed in registers] > > > are passed in the parameter words of the caller=E2=80=99s stack frame. > > > [...= > > > ] > > > float, long long (where implemented), and double arguments are > > > considered to have 8-byte size and alignment, *with float arguments > > > converted to double representation*. " > > > > > > Does anyone know the reason why the gcc passes the argument as single > > > float? > > > > Hi, Bernhard > > > > First, are you certain that you have the final version of the 32 bit > > PPC eABI? There were a few versions in circulation. > > > > Mike may remember the history of this. > > Well I worked on it around 1980 or so. I don't remember the details (nor do I > have the original manuals I was working from). From this distance, it sure > looks like a bug, but I'm not sure whether it should be fixed or > grand-fathered > in (and updating the stdargs.h support, if this is the offical calling > sequence). I recall this question coming up before, and we decided to leave gcc as is so that new ppc32 gcc code stayed compatible with old ppc32 gcc code. Also, even if we were starting with a clean slate, we might want to pass floats without promoting to double: Stack frames are potentially smaller. Against that is the fact that we promote to double when calling an unprototyped function, so you'll run into trouble trying to define a function with more than eight float args if writing K&R code. Old programmers tend to know about such issues, and don't use float function parameters in K&R code. :) Incidentally, there are other rather more nasty parameter passing problems with ppc32, ones I would have liked to fix. For instance, "complex double" is passed in 4 gprs. -- Alan Modra Australia Development Lab, IBM
Re: ppc eabi float arguments
On Thu, Sep 24, 2015 at 01:21:07AM +0200, Gabriel Paubert wrote: > You worked on PPC 10 years before the first Power systems were > announced? > > Amazing foresight :-) Ok, I was mis-remembering the dates when I started at Cygnus Solutions (forgetting the Open Software Foundation period). Lets see, I started at Cygnus in December of 1994, which would mean my initial work on Power to convert the AIX abi to System V.4/eabi would have started in early 1995. Looking at eabi.h which was added when I started the System V/eABI work, it was added in 1995. It looks like the date listed that Richard Kenner contributed the rs6000.c file was 1991. So, while I wasn't involved with Power/PowerPC at the time, it is fairly close to the 1990 date I mentioned. According to wikipedia, the first Power1 (i.e. rs/6000) were introduced in February 1990. https://en.wikipedia.org/wiki/RS/6000 -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Re: [c++std-parallel-2008] Re: Compilers and RCU readers: Once more unto the breach!
On Wed, Sep 23, 2015 at 03:30:34PM -0700, Hans Boehm wrote:
> I'd really like this to converge. It's great that it tries to focus on a
> couple of alternatives. But I'm not sure they're the right ones.
>
> I kind of like the 7.9 approach of restricting dependency chain to those
> case in which no sane existing optimization break the dependency anyway.
> The hope would then be that we can restrict future optimizations to not do
> so either without too much cost. But I'm again very concerned as to
> whether this can be specified acceptably.
>
> The paper discusses the problem with pointer comparisons that effectively
> allow the compiler to remove a dependency by inferring the identity of a
> pointer. I don't see how to describe the set of all such cases in a way
> that's comprehensible and acceptable in a standard.
>
> Consider:
>
> p = x;
> y = p -> a;
> if (x == well_known_pointer) {
> foo(well_known_pointer -> a);
> z = true;
> } else {
> y = 2;
> z = false;
> }
>
> Clearly if z = true, the load of y should have depended on that of x. But
> this should be transformed to:
>
> p = x;
> if (x == well_known_pointer) {
> foo(y = well_known_pointer -> a);
> z = true;
> } else {
> y = 2;
> z = false;
> }
>
> which no longer has that property. And I suspect we can construct examples
> in which the conditional is in a subsequent inlined function call, and
> entirely invisible to the programmer. And there are probably issues with
> compilers using more complicated chains of reasoning to infer that pointers
> must be equal, e.g. because anything else would result in undefined
> behavior. I'm once again being doubtful that we can pull off anything
> along these lines.
Indeed, the first paragraph of "Equality comparisons" on page 32 says
"This dependency-chain breakage can back-propagate to earlier uses of
the pointer". The "Narrowing magnitude comparisons" paragraph on that
same page makes this same point for sequences of inequality comparisons
that allow the compiler to deduce the exact value of the pointer.
The comparisons currently in the Linux kernel are against compile-time
initialized constant-value structures, in which case breaking the
dependency chain is OK.
I agree that the compiler could legally introduce a pointer comparison,
as noted in the "Equality comparisons" section, for example, when using
feedback-directed profiling. Do you see other reasons why the compiler
would do this?
> 7.10 looks like a good direction, but it seems to me that we need to say
> more about handling expression temporaries and function results.
> Presumably at least ordinary expression temporaries implicitly carry
> dependencies? Thus if both x and y are marked with _Carries_dependency,
> then
>
> y = ((x ^ x) & 0) * 0
>
> carries a dependency from x to y?
Yes, but a high-quality implementation would be capable of issuing a
warning in this case. After all, the developer presumably used
memory_order_consume to gain better performance, but in this case
that added performance is reduced or perhaps even eliminated completely
by the additional code required to maintain the dependency chain.
The reason for carrying the dependency in this case is instead to make
it easier on the people producing tooling.
> I'm leaning again towards something similar to what we attempted to specify
> in the current standard, but restricted to temporaries, maybe function
> locals, and explicitly annotated locations. This would be some combination
> of 7.10 and maybe 7.5. It has the down side that it will likely require a
> bunch of explicit attributes (or some kind of C equivalent, though I'm not
> sure storage class works well for function arguments and results). But it
> should avoid the kill-dependency proliferation required by the current
> standard. And we could start to actually clean up the remaining problems
> with carries_dependency.
The nice thing about having some sort of marking is that it helps in
generation of good diagnostics. We also need dependency chains to pass
into and out of functions, and this need will become more acute as
link-time optimization becomes more mainstream, which can remove the
function-call overhead from calls to external functions. We need the
compiler to know for sure whether or not a given formal parameter or
return value carries a dependency, so some sort of marking is required.
In addition, where structures (as opposed to pointers/references to
structures) are passed into and out of functions, we will very likely
need some way to mark the fields of those structures that are expected
to carry dependencies. (The Linux kernel tends to avoid this, which
I like, but other projects are likely to make other choices, regardless
of my opinions.)
That marking could be the [[carries_dependency]] attribute (at least
assuming that C adds attributes), a type modifier (which might or might
not go over well in Core), a variable modifier (which I don't un
Re: ppc eabi float arguments
On Wed, Sep 23, 2015 at 07:09:43PM -0400, Michael Meissner wrote: > On Tue, Sep 22, 2015 at 01:43:55PM -0400, David Edelsohn wrote: > > On Tue, Sep 22, 2015 at 1:39 PM, Bernhard Schommer > > wrote: > > > Hi, > > > > > > if been working with the windriver Diab c compiler for 32bit ppc for and > > > encountered an incompatibly with the eabi version of the gcc 4.83. When > > > calling functions with more than 8 float arguments the gcc stores the 9th > > > float argument (and so on) as a float where as the diab compiler stores > > > the > > > argument as a double using 8 byte. > > > > > > I checked the EABI document and it seems to support the way the diab > > > compiler passes the arguments: > > > > > > "Arguments not otherwise handled above [i.e. not passed in registers] > > > are passed in the parameter words of the caller=E2=80=99s stack frame. > > > [...= > > > ] > > > float, long long (where implemented), and double arguments are > > > considered to have 8-byte size and alignment, *with float arguments > > > converted to double representation*. " > > > > > > Does anyone know the reason why the gcc passes the argument as single > > > float? > > > > Hi, Bernhard > > > > First, are you certain that you have the final version of the 32 bit > > PPC eABI? There were a few versions in circulation. > > > > Mike may remember the history of this. > > Well I worked on it around 1980 or so. You worked on PPC 10 years before the first Power systems were announced? Amazing foresight :-) > I don't remember the details (nor do I > have the original manuals I was working from). From this distance, it sure > looks like a bug, but I'm not sure whether it should be fixed or > grand-fathered > in (and updating the stdargs.h support, if this is the offical calling > sequence). Gabriel
Re: ppc eabi float arguments
On Tue, Sep 22, 2015 at 01:43:55PM -0400, David Edelsohn wrote: > On Tue, Sep 22, 2015 at 1:39 PM, Bernhard Schommer > wrote: > > Hi, > > > > if been working with the windriver Diab c compiler for 32bit ppc for and > > encountered an incompatibly with the eabi version of the gcc 4.83. When > > calling functions with more than 8 float arguments the gcc stores the 9th > > float argument (and so on) as a float where as the diab compiler stores the > > argument as a double using 8 byte. > > > > I checked the EABI document and it seems to support the way the diab > > compiler passes the arguments: > > > > "Arguments not otherwise handled above [i.e. not passed in registers] > > are passed in the parameter words of the caller=E2=80=99s stack frame. [...= > > ] > > float, long long (where implemented), and double arguments are > > considered to have 8-byte size and alignment, *with float arguments > > converted to double representation*. " > > > > Does anyone know the reason why the gcc passes the argument as single float? > > Hi, Bernhard > > First, are you certain that you have the final version of the 32 bit > PPC eABI? There were a few versions in circulation. > > Mike may remember the history of this. Well I worked on it around 1980 or so. I don't remember the details (nor do I have the original manuals I was working from). From this distance, it sure looks like a bug, but I'm not sure whether it should be fixed or grand-fathered in (and updating the stdargs.h support, if this is the offical calling sequence). -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
gcc-4.9-20150923 is now available
Snapshot gcc-4.9-20150923 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150923/ 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 228064 You'll find: gcc-4.9-20150923.tar.bz2 Complete GCC MD5=b7c99379e5f964fb2464e4ff6ffdac5c SHA1=709ac1a3bfee843a098f41b36078ebfa8a27ff07 Diffs from 4.9-20150916 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: [cfe-dev] RFC: Support x86 interrupt and exception handlers
On Tue, Sep 22, 2015 at 11:13 AM, Richard Henderson wrote:
>
> HJ, I think Hal is right. Providing the data via arguments is vastly superior
> to providing it via builtins. I had actually been thinking the same thing
> myself.
>
> It should be easy to check that the function has the correct signature in the
> hook adding the attribute. It should also be easy to check for the attribute
> at the beginning of ix86_function_arg et al, in order to handle these special
> cases.
>
Thanks for all feedbacks. Here is the updated spec.
--
H.J.
---
The interrupt and exception handlers are called by x86 processors. X86
hardware pushes information onto stack and calls the handler. The
requirements are
1. Both interrupt and exception handlers must use the 'IRET' instruction,
instead of the 'RET' instruction, to return from the handlers.
2. All registers are callee-saved in interrupt and exception handlers.
3. The difference between interrupt and exception handlers is the
exception handler must pop 'ERROR_CODE' off the stack before the 'IRET'
instruction.
The design goals of interrupt and exception handlers for x86 processors
are:
1. Support both 32-bit and 64-bit modes.
2. Flexible for compilers to optimize.
3. Easy to use by programmers.
To implement interrupt and exception handlers for x86 processors, a
compiler should support:
'interrupt' attribute
Use this attribute to indicate that the specified function with
mandatory arguments is an interrupt or exception handler. The compiler
generates function entry and exit sequences suitable for use in an
interrupt handler when this attribute is present. The 'IRET' instruction,
instead of the 'RET' instruction, is used to return from interrupt or
exception handlers. All registers, except for the EFLAGS register which
is restored by the 'IRET' instruction, are preserved by the compiler.
Any interruptible-without-stack-switch code must be compiled with
-mno-red-zone since interrupt handlers can and will, because of the
hardware design, touch the red zone.
1. interrupt handler must be declared with a mandatory argument:
#ifdef __x86_64__
typedef unsigned long long int uword_t;
#else
typedef unsigned int uword_t;
#endif
struct interrupt_frame
{
uword_t ip;
uword_t cs;
uword_t flags;
uword_t sp;
uword_t ss;
};
__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame)
{
...
}
2. exception handler:
The exception handler is very similar to the interrupt handler with
a different mandatory function signature:
__attribute__ ((interrupt))
void
f (struct interrupt_frame *frame, uword_t error_code)
{
...
}
and compiler pops `ERROR_CODE' off stack before the 'IRET' instruction.
The exception handler should only be used for exceptions which push an
error code and all other exceptions must use the interrupt handler.
The system will crash if the wrong handler is used.
Re: does "assign_stack_local" from "function.h" automatically Do The Right Thing with debug information? [relates to the RTL-level if-conversion improvement project]
On 09/23/2015 02:56 PM, Abe wrote: Dear all, I have a prototype of a "New And Improved" RTL-level if-conversion, and it goes through "make check" without any new regressions [on AMD64 GNU/Linux, Ubuntu 14.04.3 LTS] and can pass the bootstrap stage2-to-stage3 comparison [same platform] *_if_* I prevent the "bootstrap-debug" value for BUILD_CONFIG from being automatically chosen, e.g. via "--with-build-config=bootstrap=time" during configuration. With the default "BUILD_CONFIG=bootstrap-debug", it fails at the comparison stage. The stage0/system compiler is plain-vanilla GCC 5.2, compiled by myself [bootstrapped IIRC]. I have spot-checked manually that the file pairs of the comparison-mismatch object filenames are, in fact, different for at least one such filename, using the "--preserve" option of "contrib/compare-debug". In at least many [if not all] such pairs, the file size is actually different. I wonder if "assign_stack_local" from "function.h" automatically Does The Right Thing with debug information? Especially, does it cause the debug information, if any, for stack-frame size to be updated accordingly? If not, then would switching to "assign_stack_temp" be very likely to solve the problem? Neither inherently affects debug information. So if one is working and the other not, there's a deeper problem elsewhere. Jeff
Re: Why use "assign_stack_local" instead of using "assign_stack_temp", both from "function.h"? [relates to the RTL-level if-conversion improvement project]
On 09/23/2015 02:50 PM, Abe wrote: Dear all, What, if anything, is the reason I should be using "assign_stack_local" instead of using "assign_stack_temp", both from "function.h"? The stack slot in question doesn`t need to hold its value: it is being used for a scratchpad, i.e. garbage data; basically, I just need an address for a big-enough-and-aligned-enough slot which I can safely corrupt what`s in it. It should be OK from my code`s POV if another part of the compiler causes a scratchpad slot to be reused, even if it is reused in the same routine in a single execution on the target. If you're allocating your slot late (past the gimple/rtl border), then there isn't a significant difference (ie, no reuse/sharing the slot). So if you're lazily allocating the slot, it shouldn't really matter which you use. jeff
Re: Powerpc atomic_load
On Wed, 2015-09-23 at 16:15 +0200, Sebastian Huber wrote: > On 10/09/15 19:52, David Edelsohn wrote: > > https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html > > Is there specific reason why the SYNC L,E (Elemental Memory Barriers) > defined by Power-ISA V2.07 doesn't appear in this table? Probably because that category is only implemented on some (one?) cpus (eg, E6500) and not on any of the server cpus (eg, power[45678]), so no one cared enough to add that info? :-) It would probably be useful to add though. Peter
Re: Powerpc atomic_load
On 10/09/15 19:52, David Edelsohn wrote: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html Is there specific reason why the SYNC L,E (Elemental Memory Barriers) defined by Power-ISA V2.07 doesn't appear in this table? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
