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.
> 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
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
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
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 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
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 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
[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 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
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 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 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)
>
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
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
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.
>> >
>
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
17 matches
Mail list logo
