On Fri, May 30, 2014 at 09:22:30PM +0200, Florian Weimer wrote:
> On 05/26/2014 09:38 AM, Alan Modra wrote:
>
> >Background: The ELFv2 ABI requires a parameter save area only when
> >stack is actually used to pass parameters, and since varargs are
> >passed on the stack, unprototyped calls must pa
On Fri, May 30, 2014 at 11:27:52AM -0600, Jeff Law wrote:
> On 05/26/14 01:38, Alan Modra wrote:
> >PR61300 shows a need to differentiate between incoming and outgoing
> >REG_PARM_STACK_SPACE for the PowerPC64 ELFv2 ABI, due to code like
> >function.c:assign_parm_is_stack_parm determining that a st
Currently within the GCC rs6000 backend, the type TFmode is the default 128-bit
floating point type. Depending on TARGET_IEEEQUAD (the internal name for the
-mabi=ieeelongdouble option), this gets mapped into either the IEEE 128-bit
format or the IBM extended double format. In theory, any place t
I assume we do not want a flag day, where the user flips a switch, and long
double is now IEEE 128-bit. That would involve having 2 sets of libraries,
etc. to work with existing programs and new programs. Even if the user does
not directly use long double, it still may be visible with the switch,
Right now the rs6000 backend of the GCC compiler is rather inconsistant in the
names used for the IBM extended double floating point.
For the basic operations it used __gcc_q:
__gcc_qadd
__gcc_qsub
__gcc_qmul
__gcc_qdiv
__gcc_qneg
__gcc_qne
I'm going to try and summarize the current state of 128-bit floating point on
the PowerPC here.
There are 2 switches that control long double support in the compiler, but
without supporting libraries, it isn't useful to users:
-mabi=ieeelongdouble vs. -mabi=ibmlongdouble:
These switches
I'm sorry for a wide angle shotgun approach, but I wanted to discuss with all
of the stakeholders how to phase in IEEE 128-bit floating point to the PowerPC
toolchain. For those of you who are not on the gcc@gcc.gnu.org mailing list,
this thread will be archived at: https://gcc.gnu.org/ml/gcc/
Wh
On 05/26/2014 09:38 AM, Alan Modra wrote:
Background: The ELFv2 ABI requires a parameter save area only when
stack is actually used to pass parameters, and since varargs are
passed on the stack, unprototyped calls must pass both on the stack
and in registers. OK, easy you say, !prototype_p(fun)
On 05/25/14 18:19, Matt Thomas wrote:
But even if movhi is a define_expand, as far as I can tell there's
isn't enough info to know whether that is possible. At that time,
how can I tell that operands[0] will be a hard reg or operands[1]
will be subreg of a mode dependent memory access?
At that
On 05/26/14 01:38, Alan Modra wrote:
PR61300 shows a need to differentiate between incoming and outgoing
REG_PARM_STACK_SPACE for the PowerPC64 ELFv2 ABI, due to code like
function.c:assign_parm_is_stack_parm determining that a stack home
is available for incoming args if REG_PARM_STACK_SPACE is
Dear Eric,
Really Appreciate your reply here and made the following changes like
#define ARG_POINTER_REGNUM 8 //Fake hard reg
#define FRAME _POINTER_REGNUM 9 // Fake hard reg
#define SP_REG 10
#define ELIMINABLE_REGS { {ARG_POINTER_REGNUM,STACK_POINTER_REGNUM},\
> ARG_POINTER_REGNUM and FRAME_POINTER_REGNUM need to be pseudo-registers if
> they do not represent real registers.
The wording "pseudo registers" is obviously a bit confusing in this context...
If ARG_POINTER_REGNUM and FRAME_POINTER_REGNUM do not represent real registers
then they need to be
12 matches
Mail list logo
