Chung-Lin Tang writes:
> On 2012/8/30 02:44 AM, Richard Sandiford wrote:
>> Chung-Lin Tang writes:
>>> On 2012/7/6 02:23 PM, Richard Sandiford wrote:
Richard Sandiford writes:
>> (3) Also related to libraries, I edited CRT_CALL_STATIC_FUNCTION to emit
>> a 32-bit code sequence under
On 2012/8/30 02:44 AM, Richard Sandiford wrote:
> Chung-Lin Tang writes:
>> On 2012/7/6 02:23 PM, Richard Sandiford wrote:
>>> Richard Sandiford writes:
> (3) Also related to libraries, I edited CRT_CALL_STATIC_FUNCTION to emit
> a 32-bit code sequence under both MIPS/MIPS16 mode (under O
Chung-Lin Tang writes:
> On 2012/7/6 02:23 PM, Richard Sandiford wrote:
>> Richard Sandiford writes:
(3) Also related to libraries, I edited CRT_CALL_STATIC_FUNCTION to emit
a 32-bit code sequence under both MIPS/MIPS16 mode (under O32).
As you can see in the original Feb. pat
On 2012/7/6 02:23 PM, Richard Sandiford wrote:
> Richard Sandiford writes:
>>> (3) Also related to libraries, I edited CRT_CALL_STATIC_FUNCTION to emit
>>> a 32-bit code sequence under both MIPS/MIPS16 mode (under O32).
>>>
>>> As you can see in the original Feb. patch, I had changes to emit a
>>>
Chung-Lin Tang writes:
>> __builtin_thread_pointer is logically a separate patch anyway.
>> In case it isn't clear, the reason I'm pushing back about the
>> target-dependent thing is that you're adding a fair bit of extra
>> code to the general MIPS built-in infrastructure in order to
>> handle th
On 2012/7/6 02:23 PM, Richard Sandiford wrote:
> Richard Sandiford writes:
>>> (3) Also related to libraries, I edited CRT_CALL_STATIC_FUNCTION to emit
>>> a 32-bit code sequence under both MIPS/MIPS16 mode (under O32).
>>>
>>> As you can see in the original Feb. patch, I had changes to emit a
>>>
Richard Sandiford writes:
>> (3) Also related to libraries, I edited CRT_CALL_STATIC_FUNCTION to emit
>> a 32-bit code sequence under both MIPS/MIPS16 mode (under O32).
>>
>> As you can see in the original Feb. patch, I had changes to emit a
>> MIPS16 version of these static calls, but with the ch
Thanks for the update.
Chung-Lin Tang writes:
> As for the issue of making __builtin_thread_pointer()
> target-independent, while it's possible, it seems that most such
> builtins are functionality that lends to a machine-independent
> implementation when no target-hooks are provided. A thread po
Hi Richard,
picking up a yet uncommitted part of the MIPS16 changes, see below:
On 2012/2/3 11:28 PM, Richard Sandiford wrote:
> Chung-Lin Tang writes:
>>> (2) is interesting if there is also a way to build those MIPS16 libraries
>>> out of the box. I'd like such a mechanism to be added at the s
On Sun, 19 Feb 2012, Richard Sandiford wrote:
> > The i386 target does it all the time for its __x86.get_pc_thunk.?x thingys.
>
> Thanks for the pointer. Here's a patch that takes the same approach.
> There's no problem relying on comdat groups here, since MIPS16 TLS
> requires 2.22 gas and ld a
Richard Henderson writes:
> On 02/04/2012 02:06 AM, Richard Sandiford wrote:
>>> > Actually I had that idea of a link-once function too, but it turned out
>>> > quite complicated to do without rewriting some generic parts of GCC as it
>>> > is currently not prepared to emit link-once functions
On Sat, 11 Feb 2012, Richard Henderson wrote:
> On 02/04/2012 02:06 AM, Richard Sandiford wrote:
> >> > Actually I had that idea of a link-once function too, but it turned out
> >> > quite complicated to do without rewriting some generic parts of GCC as
> >> > it
> >> > is currently not prepar
On 02/04/2012 02:06 AM, Richard Sandiford wrote:
>> > Actually I had that idea of a link-once function too, but it turned out
>> > quite complicated to do without rewriting some generic parts of GCC as it
>> > is currently not prepared to emit link-once functions outside C++
>> > compilations.
[forking for different topics]
"Maciej W. Rozycki" writes:
> On Sat, 4 Feb 2012, Richard Sandiford wrote:
>> > I don't think _mcount has ever worked for dynamic libraries, has it? --
>> > please correct me if I am wrong, but I believe `gprof' relies on memory
>> > segments to be contiguous whi
"Maciej W. Rozycki" writes:
>> > We have only about now got MIPS16 shared libraries to work -- are you
>> > sure removing code to save/restore $2/$3 in the dynamic linker is going to
>> > hit anyone?
>>
>> Pretty sure. There are two separate points here. Support for MIPS16
>> shared librarie
On Sat, 4 Feb 2012, Richard Sandiford wrote:
> > I don't think _mcount has ever worked for dynamic libraries, has it? --
> > please correct me if I am wrong, but I believe `gprof' relies on memory
> > segments to be contiguous which is certainly not the case for a dynamic
> > executable where
Richard Sandiford writes:
> "Maciej W. Rozycki" writes:
>>> If there's still some concern that __mips16_rdhwr might not have
>>> the right ABI, then maybe we should simply emit a link-once function
>>> in each object that needs it. We could then switch to another function
>>> (and another API) w
"Maciej W. Rozycki" writes:
>> I don't think changing the resolver function so that it preserves
>> fewer registers would be a good idea. As well as the MIPS16 thing,
>> $3 is needed for _mcount.
>
> I don't think _mcount has ever worked for dynamic libraries, has it? --
> please correct me if
On Fri, 3 Feb 2012, Richard Sandiford wrote:
> > Not quite a large portion, just the function return stubs (which I reckon
> > there are exactly four) that process values in $v0/$v1 as if they were
> > arguments. This is of course a non-standard calling convention that
> > breaks the ABI and
"Maciej W. Rozycki" writes:
> On Fri, 3 Feb 2012, Chung-Lin Tang wrote:
>> On the issue of hiding stuff in mips16.S, it may be suitable to raise
>> this issue here: there is a problem when MIPS16 hard-float calls go
>> through PLTs, because the hard-float stub functions in mips16.S use
>> v0/v1 as
Chung-Lin Tang writes:
>> (2) is interesting if there is also a way to build those MIPS16 libraries
>> out of the box. I'd like such a mechanism to be added at the same time,
>> so that the new support is easy to test. This is still a 4.7 candidate
>> if it can be done in time, although it's pro
On Fri, 3 Feb 2012, Chung-Lin Tang wrote:
> On the issue of hiding stuff in mips16.S, it may be suitable to raise
> this issue here: there is a problem when MIPS16 hard-float calls go
> through PLTs, because the hard-float stub functions in mips16.S use
> v0/v1 as scratch registers, the same as MI
Hi Richard,
Sorry for the delay to respond, and thanks for revising and committing
the changes to trunk. The revised changes look much cleaner :)
About the other concerns:
> (2) is interesting if there is also a way to build those MIPS16 libraries
> out of the box. I'd like such a mechanism to
Richard Sandiford writes:
> gcc/
> 2012-01-08 Chung-Lin Tang
> Richard Sandiford
>
> * config/mips/mips-protos.h (SYMBOL_FORCE_TO_MEM): Delete.
> (SYMBOL_32_HIGH): Likewise.
> (mips_output_tls_reloc_directive): Declare.
> * config/mips/mips.h (PIC_FUNCTION_AD
Chung-Lin Tang writes:
> Hi Richard,
> here are the patches for MIPS16 TLS.
Thanks for all the work. It's great to see this hole in the MIPS16
support finally being plugged.
There seem to be three changes in the patch:
(1) Enable MIPS16 TLS (which must of course work independently
of wheth
Hi Richard,
here are the patches for MIPS16 TLS. Some highlights of the implementation:
1) For the common -mcode-readable=yes case, TP/DTP offset constants are
loaded pc-relative (this saves insn count and size). HI16/LO16
constructing is used only as a fall-back when text is not readable.
2) To
26 matches
Mail list logo
