On Tue, Aug 7, 2012 at 4:27 PM, Dimitrios Apostolou wrote:
> On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
>
>> On Tue, Aug 7, 2012 at 2:24 PM, Dimitrios Apostolou wrote:
>>>
>>>
>>> BTW I can't find why ELF_STRING_LIMIT is only 256, it seems GAS supports
>>> arbitrary lengths. I'd have to change m
On Tue, 7 Aug 2012, Ian Lance Taylor wrote:
On Tue, Aug 7, 2012 at 2:24 PM, Dimitrios Apostolou wrote:
BTW I can't find why ELF_STRING_LIMIT is only 256, it seems GAS supports
arbitrary lengths. I'd have to change my code if we ever set it too high (or
even unlimited) since I allocate the buf
On Tue, Aug 7, 2012 at 2:24 PM, Dimitrios Apostolou wrote:
>
> BTW I can't find why ELF_STRING_LIMIT is only 256, it seems GAS supports
> arbitrary lengths. I'd have to change my code if we ever set it too high (or
> even unlimited) since I allocate the buffer on the stack.
See the comment for EL
I should mention that with my patch .ascii is used more aggresively than
before, so if a string is longer than ELF_STRING_LIMIT it will be written
as .ascii all of it, while in the past it would use .string for the
string's tail. Example diff to original behaviour:
.LASF15458:
- .ascii
On Tue, 7 Aug 2012, Dimitrios Apostolou wrote:
> Thanks Andreas, hp, Mike, for your comments. Mike I'd appreciate if you
> elaborated on how to speed-up sprint_uw_rev(), I don't think I understood what
> you have in mind.
I just commented on comments and just above the nit-level;
formatting and co
Hello list,
these clean-ups and minor speedups complete some TODOs and semi-finished
changes I have gathered in the ELF backend. In a nutshell:
Fixed comment style, used INT_BITS_STRLEN_BOUND from gnulib to be future
proof on integer representation string length, replaced long arguments in
f
Dimitrios Apostolou writes:
> @@ -3849,6 +3850,32 @@ sprint_ul_rev (char *s, unsigned long va
>return i;
> }
>
> +/* Write a signed HOST_WIDE_INT as decimal to a file, fast. */
> +
> +void
> +fprint_w (FILE *f, HOST_WIDE_INT value)
> +{
> + /* python says: len(str(2**64)) == 20 */
> + ch
On Jul 9, 2012, at 12:54 PM, Dimitrios Apostolou wrote:
> Since output_addr_const() shows pretty hot in the compiler, I reinstated the
> fprint_w() call in place of fprintf().
My review bits... First there is no guarantee that HOST_WIDE_INT_BITSIZE is 64
or less, so [20] is unsafe longer term.
On Mon, 9 Jul 2012, Dimitrios Apostolou wrote:
> Since output_addr_const() shows pretty hot in the compiler, I reinstated the
> fprint_w() call in place of fprintf().
>
> This patch relies on two things: 2's complement representation for negative
> int and that HOST_WIDE_INT is at least as large ty
Since output_addr_const() shows pretty hot in the compiler, I reinstated
the fprint_w() call in place of fprintf().
This patch relies on two things: 2's complement representation for
negative int and that HOST_WIDE_INT is at least as large type as long for
all platforms (will it always be?).
10 matches
Mail list logo
