On Mon, Jun 30, 2014 at 2:35 PM, Ulrich Drepper wrote:
> Using LTO to create a DSO works fine (i.e., it performs the expected
> optimizations) for symbols which are marked with visibility
> attributes. It does not work, though, when the symbol is not
> restricted in its visibility in the source f
On Wed, Jul 2, 2014 at 7:10 AM, DJ Delorie wrote:
>
> Revisiting an old thread, as I still want to get this feature in...
>
> https://gcc.gnu.org/ml/gcc/2012-10/msg00099.html
>
>> >> Why do you need to change varasm.c at all? The hunks seem to be
>> >> completely separate of the attribute.
>> >
>
Hi All,
Currently GCC permanently reserves EBX as the GOT register.
(config/i386/i386.c:4289)
/* The PIC register, if it exists, is fixed. */
j = PIC_OFFSET_TABLE_REGNUM;
if (j != INVALID_REGNUM)
fixed_regs[j] = call_used_regs[j] = 1;
This leads to significant per
Hi Tobias,
I think that, according to the std::map feedback, we could use
std::map now and replace it with hash_map later, if its performance is
better. However, I propose to temporary postpone this and work on
gimple code generation from isl_ast_node_user, because we already have
generation of lo
On Mon, Jul 7, 2014 at 12:00 PM, Evgeny Stupachenko wrote:
> Hi All,
>
> Currently GCC permanently reserves EBX as the GOT register.
>
> (config/i386/i386.c:4289)
>
> /* The PIC register, if it exists, is fixed. */
> j = PIC_OFFSET_TABLE_REGNUM;
> if (j != INVALID_REGNUM)
>
On 05/07/2014 00:03, Trevor Saunders wrote:
On Fri, Jul 04, 2014 at 09:57:11AM +0200, Tobias Grosser wrote:
On 04/07/2014 04:16, Trevor Saunders wrote:
On Thu, Jul 03, 2014 at 07:52:59PM +0200, Tobias Grosser wrote:
On 03/07/2014 19:23, Roman Gareev wrote:
Dear gcc contributors,
could you pl
On 7 July 2014 12:08, Tobias Grosser wrote:
>
> The number of elements in these maps is most likely between 3-10.
Then std::map is the wrong solution.
The overhead of dereferencing all the pointers while walking through a
std::map will be higher than the savings you get from logarithmic
lookup.
On 07/07/2014 12:33, Roman Gareev wrote:
Hi Tobias,
I think that, according to the std::map feedback, we could use
std::map now and replace it with hash_map later, if its performance is
better. However, I propose to temporary postpone this and work on
gimple code generation from isl_ast_node_use
[Forgot to answer two questions]
On 07/07/2014 12:33, Roman Gareev wrote:
Hi Tobias,
I think that, according to the std::map feedback, we could use
std::map now and replace it with hash_map later, if its performance is
better.
Right.
> However, I propose to temporary postpone this and work o
On 07/07/2014 13:14, Jonathan Wakely wrote:
On 7 July 2014 12:08, Tobias Grosser wrote:
The number of elements in these maps is most likely between 3-10.
Then std::map is the wrong solution.
The overhead of dereferencing all the pointers while walking through a
std::map will be higher than t
The key problem here is that EBX is not used in register allocation.
If we relax the restriction on EBX the performance is back, but there
are several fails.
Some of them could be fixed.
However I don't like that way as EBX register is uninitialized at
register allocation.
Initialization (SET_GOT)
On Mon, Jul 07, 2014 at 03:35:06PM +0400, Evgeny Stupachenko wrote:
> The key problem here is that EBX is not used in register allocation.
> If we relax the restriction on EBX the performance is back, but there
> are several fails.
> Some of them could be fixed.
> However I don't like that way as E
On 07/07/14 04:42, Richard Biener wrote:
1.
While call expand emit SET_GOT -> EBX and MOV EBX -> some local register: LGOT
Prior to each call emit MOV LGOT -> EBX
Use LGOT as new GOT register for globals.
2.
Set EBX as each CALL parameter.
Emit MOV EBX->LGOT in each call.
Use LGOT as new GOT r
On Mon, Jul 7, 2014 at 1:47 PM, Jakub Jelinek wrote:
> On Mon, Jul 07, 2014 at 03:35:06PM +0400, Evgeny Stupachenko wrote:
>> The key problem here is that EBX is not used in register allocation.
>> If we relax the restriction on EBX the performance is back, but there
>> are several fails.
>> Some
2014-07-07 15:47 GMT+04:00 Jakub Jelinek :
> On Mon, Jul 07, 2014 at 03:35:06PM +0400, Evgeny Stupachenko wrote:
>> The key problem here is that EBX is not used in register allocation.
>> If we relax the restriction on EBX the performance is back, but there
>> are several fails.
>> Some of them cou
> Ok, but as we are dealing exclusively with bitfields there is
> already output_constructor_bitfield which uses an intermediate
> state to "pack" bits into units that are then emitted. It shouldn't
> be hard to change that to make it pack into the appropriate bits
> instead.
That assumes that t
Hi Community,
All GCC GSoC students have successfully passed mid-term evaluations, and are
continuing to work on their projects. Congratulations to all the students!
Furthermore, Linaro has generously provided sponsorship to pay for 1 GCC GSoC
student to travel to GNU Tools Cauldron this year.
17 matches
Mail list logo
