[Bug ports/28872] Building glibc for MIPSel single float targets

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28872

--- Comment #9 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Den from comment #8)
> (In reply to Adhemerval Zanella from comment #7)
> > About your patch, it does seems fully correct since you replacing a double
> > load/store with a float load/store.  It will most likely trigger failures
> > in mips processors that fully implement double instructions.
> From other side, since everything is planned to operate with doubles, I
> doubt that the redefinition of the fpregs in mips'es setjmp.h
> from
> double __fpregs[6];
> to
> float __fpregs[12];
> is correct. I think it have to be as it is, __fpregs[6], instead.
> 
> The theory is we'll be getting the incoming double, halfing it and storing
> into the free registers and the higher part registers respectively.
> The practice. Mips'es file setjmp_aux.c:
> 
> asm volatile ("s.d $f20, %0" : : "m" (env[0].__jmpbuf[0].__fpregs[0]));
> 
> compiling it to get the object file. The appropriate to that line now is the
> next:
> 
> s.d $f20, 56($4)
> 
> I think that it is needed to be rewritten to the next:
> 
> swc1 $f20, 56($4)
> swc1 $f21, 60($4)
> 
> Then back to asm volatile. I could not achieve as to rewrite it here. I'm
> sure it should be looking like this:
> asm volatile ("swc1 $f20, ?\n\t
>                swc1 $f21, ?"
>               :
>               : "?" ( ? ));
> 
> That's why I redefined __fpregs from double to float - to get them incoming
> by 4 instead of by 8 and so on I wrote a separated asm volatiles which might
> be a mistake here too, and it should be united. Can you in this particular
> example rewrite it as to get the lower and higher parts of the incoming
> __fpregs[0] and respectively return those data to $f20 and $f21 to store?

You can't change the size unless you want either define case as a new ABI 
(so you will need to provide a new setjmp.h and all machinery to select this
as a new ABI, probably to set a new triple, etc.).  Also, changing it size
is a ABI change, you will need to considere all the implication of doing it.

Accessing the __fpregs members should be transparent to the application, setjmp
should place the information in a form the compiler generated code could
retrieve
the information.  I am not if you need to emit a extend or trunc operation,
I am trying to understand which options you use with gcc to target this chip, 
-mabi=32 -march=mips2 -mhard-float -msingle-float -mfp32 seems to use 'sw/lw'
to
load store doubles.

> 
> > It will most likely trigger failures
> > in mips processors that fully implement double instructions.  As before, 
> > I think you will need to only use this code patch if __mips_fpr equal to
> > 32 (I am not sure about __mips_fpr being 0).
> 
> > checking __mips_fpr and setting macros for float and double load/store
> Yes it might work, setjmp_aux.c "knows" about the definition of the
> __mips_fpr which is 32. I just presented the patch to show the logic of the
> rewritting, which is doubtful...
> 
> > The sqrt implementation was refactor by 2.32 by 32c65b28f37fc6c, to it now
> > uses compiler_builtin.
> Yes, I saw it before and tried to implement it in 2.30. If I'd know that it
> is approved in the v2.32 and newer, I just used the updated glibc to
> compile. And I'm surely will.

I didn't not understand what it should 'approved' here.  If you want to get
this fixed upstream you will need to patch against master.

> 
> > The setjmp.h/jmp_buf-macros.h change is also wrong: they are installed
> > headers that do define the ABI, so you if you changing you de-facto
> > creating a new ABI or you need all the dance to provide compatibility
> > symbols
> Understood and agreed. And I think that's the hint that __fpregs should be
> stayed at [6] numbers of doubles definition. Just to understand the
> conception of halfing the double in the assembler...
> 
> > In any case I suggest you to prepare a patch, even if incomplete, so we
> > can discuss on libc-alpha.
> > 
> > [1] https://sourceware.org/glibc/wiki/Contribution%20checklist
> Alright, I'll involve into it. Should I attach it here or to create some
> separate bug request as suggested?

Just reference the bugzill number in patch title 'Title (BZ #XXXXX)', patches
are reviewed only on the maillist.

-- 
You are receiving this mail because:
You are on the CC list for the bug.