Re: Bug in expand_builtin_setjmp_receiver ?
On 22 October 2010 20:17, Ian Lance Taylor wrote: > Frederic Riss writes: >> OK... what's the best way forward on this? Do we just leave it as it >> is and wait until an official port needs complains about it? Should it >> be filled in bugzilla? > > Did you just happen to come across this, or is this relevant for a port > you are working on? I came accross that while working on a port, however I don't know if/when it will be opened. I suppose that if the port wants to be integrated one day, then a fix for that issue might be part of the patch series for that port? > If you are not working on a port, then I think the best think to do > right now is to add a FIXME comment in the source code. I'll llet you decide if you want to do that. Thanks, Fred
combiner
In my port I get to such a situation:
(insn 60 59 61 4 a.c:65 (set (subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0)
(zero_extract:SI (subreg:SI (reg/v:DI 138 [ v4hi1 ]) 4)
(const_int 16 [0x10])
(const_int 16 [0x10]))) 53 {extzv} (nil))
(insn 61 60 62 4 a.c:65 (set (reg:BI 159)
(gtu:BI (reg:HI 129 [ __prephitmp_4 ])
(reg/v:HI 143 [ usiThresh ]))) 94 {cmprr_hi_gtu} (nil))
The patterns for these are:
(define_insn "extzv"
[(set (match_operand:SI 0 "register_operand" "=d")
(zero_extract:SI (match_operand:SI 1 "register_operand" "d")
(match_operand:SI 2 "immediate_operand" "U06")
(match_operand:SI 3 "immediate_operand" "U06")))]
""
"extractua\t %2, %3, %1, %0 %!"
)
and
(define_insn "cmprr_hi_"
[(set (match_operand:BI 0 "register_operand" "=c")
(any_cond_rr:BI (match_operand:HI 1 "register_operand" "d")
(match_operand:HI 2 "register_operand" "d")))]
""
"cmp %2.L, %1.L, %0:%I0 %!"
)
I want the combiner to combine both insns since I have an intruction
which can compare from an HI partial register.
I am trying to write an insn pattern for that but the combiner does not use i.
I thought about something like:
(define_insn "cmprr_hi__1"
[(set (match_operand:BI 0 "register_operand" "=c")
(any_cond_rr:BI (zero_extract:SI (match_operand:DI 1
"register_operand" "d")
(const_int 16) (const_int 16))
(match_operand:HI 2 "register_operand" "d")))]
""
"cmp %2.L, %1.L, %0:%I0 %!"
)
but it does not work.
Can someone please help?
Thanks, Roy.
Constant propagation and CSE
Hi, The constant propagation pass propagates constants into the instructions that accept immediates. I'm trying to find if there's some CSE pass in GCC that would be able to undo this effect when the constant is used more than once in the function. I looked at the CSE code (4.5 branch) and I don't think this is currently possible. If the code uses a bunch of big constants, the effect on code size might be quite sensible. I hacked around that in a quite horrible manner: I arranged for the immediate alternative of some insn patterns to be invalid during the 'cprop' passes. That way cprop doesn't put the immediate into the instructions, but if the constant is used only once it will be propagated into the instruction by the 'combine' pass. This seems excessively hackish to me, I wanted to know if there's some better/standard way to handle that issue. Thanks, Fred
Re: peephole2: dead regs not marked as dead
Paolo Bonzini schrieb:
> On 10/22/2010 01:16 PM, Georg Lay wrote:
>> Then the first insn gets split after reload and before peephole2:
>>
>> (insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
>> (and:SI (reg:SI 4 d4 [ x ])
>> (const_int -98305 [0xfffe7fff]))) 143
>> {*and3_zeroes.insert.{SI}.ic}
>> (nil))
>>
>> (insn 23 22 21 2 peep2.c:5 (set (reg:SI 15 d15)
>> (xor:SI (reg:SI 15 d15)
>> (reg:SI 4 d4 [ x ]))) 39 {*xorsi3} (nil))
>>
>> (insn 21 23 10 2 peep2.c:5 (set (reg:SI 4 d4)
>> (reg:SI 15 d15)) 2 {*movsi_insn} (nil))
>>
>> (call_insn/j 10 21 11 2 peep2.c:5 (parallel [
>> (set (reg:SI 2 d2)
>> (call (mem:HI (symbol_ref:SI ("f") [flags
>> 0x41]> 0xb76b3280 f>) [0 S2 A16])
>> (const_int 0 [0x0])))
>> (use (const_int 1 [0x1]))
>> ]) 92 {call_value_insn} (nil)
>> (expr_list:REG_DEP_TRUE (use (reg:SI 4 d4))
>> (nil)))
>> ;; End of basic block 2 -> ( 1)
>> ;; lr out 2 [d2] 26 [SP] 27 [a11]
>> ;; live out 2 [d2] 26 [SP] 27 [a11]
>> ;; Succ edge EXIT [100.0%] (ab,sibcall)
>>
>> (barrier 11 10 20)
>>
>> D15, is not marked as dead
>
> True. It should have had a REG_DEAD note. Are you using 4.6 (which
> scans forwards in peephole2 and requires REG_DEAD notes) or 4.5 (which
> scans backwards)? If the latter, the absence of the note could be a red
> herring, because 4.5 didn't need REG_DEAD notes so it didn't compute them.
It is a target port of 4.5.1. I just skimmed peep2_reg_dead_p and it looks
backward. So this function will never see that D15 dies and report D15 as alive.
> What's your definition of CALL_USED_REGISTERS,
> CALL_REALLY_USED_REGISTERS, EPILOGUE_USES? Is d15 in any of them?
D15 is not an element of any of them. D15 is call-saved and will get restored in
the RET-instruction of the callee which is tail-called in this particular case.
But even if f is not being tail-called D15 is not reported as dead. In that case
the insns after the call are (D2 is the return register, returning 1+f(...))
(insn 17 12 20 2 peep2.c:11 (set (reg/i:SI 2 d2)
(plus:SI (reg:SI 2 d2)
(const_int 1 [0x1]))) 6 {*addsi3} (nil))
(insn 20 17 28 2 peep2.c:11 (use (reg/i:SI 2 d2)) -1 (nil))
(jump_insn 29 28 30 2 peep2.c:11 (return) -1 (nil))
(barrier 30 29 23)
As far as 4.6 is concerned, I have not tried it yet. I do not know how stable
the releases are and how much work it is to switch from 4.5 to 4.6.
Georg Lay
Is it possbile to hack I386 backend to make all function calls to be indirect function calling?
Hi, I meet a requirement to make all function calls to be indirect function calling ( for I386 GCC compiler). I am not familiar with frontend, so my first idea is to hack it from backend, change the asm output for "call" and "call_value" insn patterns, generate a related varible in data section, and when output call insn, output indirect call. For example, for function A, I create a "g_stub_function_ptr_A" varible in data section, with initialized value "A", and when output call insn "A", output (I am not familiar with X86 instruction set, so I assume that there is "CALL EAX" instruction): MOV EAX, g_stub_function_ptr_A CALL EAX Will this idea works? Any comments are welcome! Ps: the orignal requirement is to make function stubs for unit test. Assume the top level function is A, and it calls B,C,D functions, B calls E, E calls F So when testing function A, one needs to care the all call chains of A, which makes the unit test hard to implement. Now I have a scratch idea: make all function calls to be indirect call, in other words, make all function calls to be function pointer call. So when testing function A, one can make stubs for B,C,D, and change the called B,C,D to be one's own defined B,C,D stubs, via asigning the function pointer to be one's own.
Re: peephole2: dead regs not marked as dead
On 10/25/2010 11:35 AM, Georg Lay wrote:
(insn 22 8 23 2 peep2.c:5 (set (reg:SI 15 d15)
(and:SI (reg:SI 4 d4 [ x ])
(const_int -98305 [0xfffe7fff]))) 143
{*and3_zeroes.insert.{SI}.ic}
(nil))
(insn 23 22 21 2 peep2.c:5 (set (reg:SI 15 d15)
(xor:SI (reg:SI 15 d15)
(reg:SI 4 d4 [ x ]))) 39 {*xorsi3} (nil))
(insn 21 23 10 2 peep2.c:5 (set (reg:SI 4 d4)
(reg:SI 15 d15)) 2 {*movsi_insn} (nil))
(call_insn/j 10 21 11 2 peep2.c:5 (parallel [
(set (reg:SI 2 d2)
(call (mem:HI (symbol_ref:SI ("f") [flags
0x41]) [0 S2 A16])
(const_int 0 [0x0])))
(use (const_int 1 [0x1]))
]) 92 {call_value_insn} (nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 4 d4))
(nil)))
;; End of basic block 2 -> ( 1)
;; lr out 2 [d2] 26 [SP] 27 [a11]
;; live out 2 [d2] 26 [SP] 27 [a11]
;; Succ edge EXIT [100.0%] (ab,sibcall)
(barrier 11 10 20)
D15, is not marked as dead
True. It should have had a REG_DEAD note. Are you using 4.6 (which
scans forwards in peephole2 and requires REG_DEAD notes) or 4.5 (which
scans backwards)? If the latter, the absence of the note could be a red
herring, because 4.5 didn't need REG_DEAD notes so it didn't compute them.
It is a target port of 4.5.1. I just skimmed peep2_reg_dead_p and it looks
backward.
In this case, as I mentioned the function _doesn't need_ a note to see
that D15 dies. There's no such thing as a register that is "naturally
dead because the function ends" and needs special treatment. Liveness
is computed like everything else from data flow and, when scanning
backwards, can be computed simply from the defs and uses of each
instruction. The notes are not necessary, so their absence is (as I
also have mentioned above already) a red herring.
The definition of liveness is lr_before = lr_after - def + use, which gives:
at the end of basic block lr from dump file = {2,26,27}
insn 10 def = {2}, use = {4} lr before insn 10 = {4,26,27}
insn 21 def = {4}, use = {15} lr before insn 21 = {15,26,27}
insn 23 def = {15}, use = {4,15} lr before insn 23 = {4,15,26,27}
insn 22 def = {15}, use = {4} lr before insn 22 = {4,26,27}
When GCC matches the peephole against 21+23, peep2_reg_dead_p(2, reg)
should test reg against "lr before insn 10". This is {4,26,27}. You
have to set a breakpoint in df_simulate_one_insn_backwards and see which
part of my theory above is incorrect.
Paolo
Re: Constant propagation and CSE
On 10/25/2010 10:46 AM, Frederic Riss wrote: Hi, The constant propagation pass propagates constants into the instructions that accept immediates. I'm trying to find if there's some CSE pass in GCC that would be able to undo this effect when the constant is used more than once in the function. I looked at the CSE code (4.5 branch) and I don't think this is currently possible. If the code uses a bunch of big constants, the effect on code size might be quite sensible. I hacked around that in a quite horrible manner: I arranged for the immediate alternative of some insn patterns to be invalid during the 'cprop' passes. That way cprop doesn't put the immediate into the instructions, but if the constant is used only once it will be propagated into the instruction by the 'combine' pass. This seems excessively hackish to me, I wanted to know if there's some better/standard way to handle that issue. You need to teach constant propagation to look at insn costs, like fwprop does. Alternatively, try rearranging passes (e.g. swapping GCSE and fwprop) so that you can delete the local copy propagation completely. :) Paolo
REGNO_OK_FOR_BASE_P
Working on the pdp11 target, I ran into something odd. It defines REGNO_OK_FOR_BASE_P in a way that seems to match what gccint says one should do in the "strict" case -- but does so all the time. Specifically, it says: #define REGNO_OK_FOR_BASE_P(REGNO) \ ((REGNO) < 8 || (unsigned) reg_renumber[REGNO] < 8) (8 because there are 8 general registers on the PDP11, all suitable as base.) It then defines another similarly named macro REG_OK_FOR_BASE_P which takes an rtx instead of a regno, for use in GO_IF_LEGITIMATE_ADDRESS. That second macro *does* come with a non-strict form which accepts all registers. Looking at gccint, that seemed wrong. As far as I can tell, REG_OK_FOR_BASE_P is not (or no longer) a standard macro so it's just a convenience macro inside the target. No problem there. But the strict REGNO_OK_FOR_BASE_P in non-strict settings seemed like an issue, so I changed it. The surprise it that it makes no difference. No change in code, no change in testsuite results. Why didn't it matter? Is the documentation wrong? Or is the existing definition somehow ok even for the non-strict case, in a way that isn't obvious? paul
Re: Is it possbile to hack I386 backend to make all function calls to be indirect function calling?
redriver jiang writes: > Hi, > > I meet a requirement to make all function calls to be indirect > function calling ( for I386 GCC compiler). I am not familiar with > frontend, so my first idea is For x86-64 using the "large" code model (-mcmodel=large) will result in all function calls being indirect. If you want to do it for 32bit you could probably extend the implementation of this feature. -Andi
Re: Discussion about merging Go frontend
On 10/24/2010 10:52 PM, Ian Lance Taylor wrote: > It's hard for me to believe that BFD is the correct answer. It's poorly > designed for the kinds of things the compiler needs to do. Any program > which links against BFD effectively links in the GNU linker. It sounded from your mail like all the compiler needs to do is to read the binary contents of a named section. Isn't that something that BFD does well? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
movmemm pattern
Question on movmemm:
Given
extern int *i, *j;
void foo (void) { memcpy (i, j, 10); }
I would expect to see argument 4 (the shared alignment) to be sizeof(int) since
both argument are pointers to int. What I get instead is 1. Why is that?
If I have
extern int i[10], j[10];
then I do get larger alignment as expected.
paul
Re: Bug in expand_builtin_setjmp_receiver ?
Frederic Riss writes: > On 22 October 2010 20:17, Ian Lance Taylor wrote: >> Frederic Riss writes: >>> OK... what's the best way forward on this? Do we just leave it as it >>> is and wait until an official port needs complains about it? Should it >>> be filled in bugzilla? >> >> Did you just happen to come across this, or is this relevant for a port >> you are working on? > > I came accross that while working on a port, however I don't know > if/when it will be opened. I suppose that if the port wants to be > integrated one day, then a fix for that issue might be part of the > patch series for that port? If you have a patch that works for your port, and a good argument to support it, and an explanation for why it doesn't affect current ports, that is sufficient to send a patch. Thanks. Ian
Re: Discussion about merging Go frontend
Mark Mitchell writes: > On 10/24/2010 10:52 PM, Ian Lance Taylor wrote: > >> It's hard for me to believe that BFD is the correct answer. It's poorly >> designed for the kinds of things the compiler needs to do. Any program >> which links against BFD effectively links in the GNU linker. > > It sounded from your mail like all the compiler needs to do is to read > the binary contents of a named section. Isn't that something that BFD > does well? BFD will get the job done. But I don't think it's a good choice for releasing a program like gcc. BFD is in effect an internal library for the linker and the GNU binutils, and it's also used by the assembler. It doesn't really maintain source compatibility across releases, and it definitely doesn't maintain binary compatibility. As I mentioned above, when you link against BFD you effectively pull in the linker. Reading a section from an object file is not hard. Linking against BFD to do it is massive overkill. If we were already linking against BFD, then sure. But introducing BFD for this will give us and the binutils developers some long-term maintenance pain for limited reward. At least, that is how I see it. Ian
Re: Discussion about merging Go frontend
On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor wrote: > At least, that is how I see it. Why not require libelf just like for LTO? That seems like a time to reduce what we depend on. For an example if we compile with lto and go, GCC will use two different elf libraries. This seems dumb really. Thanks, Andrew Pinski
Re: Discussion about merging Go frontend
Andrew Pinski writes: > On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor wrote: >> At least, that is how I see it. > > Why not require libelf just like for LTO? That seems like a time to > reduce what we depend on. For an example if we compile with lto and > go, GCC will use two different elf libraries. This seems dumb really. libelf is rather awkward and has different implementations with different bugs and also usually needs to be installed explicitely on Linux. It would be better to make LTO use Ian's library (but then it's C++ I believe, not C) -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [wwwdocs] PATCH for Re: new mirror
On Thu, 7 Oct 2010, James Miller wrote: > Our mirror address has been changed from > > http://gcc.parentinginformed.com/ > > to > > http://gcc.parentingamerica.com/ > > Please update your list to use the new URL. > > Also please use new e-mail to contact me when necessary: > jmil...@parentingamerica.com. Thanks for the heads up, James. I have updated our web site per the patch below a week ago, just failed to send this earlier. (I also noticed you put an http redirect in place which is nice; too many webmasters don't.) Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.202 diff -u -3 -p -r1.202 mirrors.html --- mirrors.html22 Sep 2010 22:11:00 - 1.202 +++ mirrors.html17 Oct 2010 16:35:00 - @@ -34,7 +34,7 @@ Key fingerprint = 33C2 35A3 4C46 AA3F FB Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, thanks to Antonin dot Sprinzl at tuwien dot ac dot at Bulgaria: http://gcc.igor.onlinedirect.bg/";>gcc.igor.onlinedirect.bg, thanks to igor at onlinedirect dot bg -Canada: http://gcc.parentinginformed.com";>http://gcc.parentinginformed.com, thanks to James Miller (jmiller at parentinginformed dot com). +Canada: http://gcc.parentingamerica.com";>http://gcc.parentingamerica.com, thanks to James Miller (jmiller at parentingamerica dot com). Canada: http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to Sergey Ivanov (mirrors at skazkaforyou dot com) China: ftp://linuxforum.net/ftp.gcc.gnu.org/";>ftp://linuxforum.net/ftp.gcc.gnu.org/, thanks to David Deng (david99deng at yahoo dot com) France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6 dot fr
Re: combiner
roy rosen writes:
> In my port I get to such a situation:
>
> (insn 60 59 61 4 a.c:65 (set (subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0)
> (zero_extract:SI (subreg:SI (reg/v:DI 138 [ v4hi1 ]) 4)
> (const_int 16 [0x10])
> (const_int 16 [0x10]))) 53 {extzv} (nil))
>
> (insn 61 60 62 4 a.c:65 (set (reg:BI 159)
> (gtu:BI (reg:HI 129 [ __prephitmp_4 ])
> (reg/v:HI 143 [ usiThresh ]))) 94 {cmprr_hi_gtu} (nil))
>
> The patterns for these are:
>
> (define_insn "extzv"
> [(set (match_operand:SI 0 "register_operand" "=d")
> (zero_extract:SI (match_operand:SI 1 "register_operand" "d")
> (match_operand:SI 2 "immediate_operand" "U06")
> (match_operand:SI 3 "immediate_operand" "U06")))]
> ""
> "extractua\t %2, %3, %1, %0 %!"
> )
>
> and
>
> (define_insn "cmprr_hi_"
> [(set (match_operand:BI 0 "register_operand" "=c")
> (any_cond_rr:BI (match_operand:HI 1 "register_operand" "d")
> (match_operand:HI 2 "register_operand" "d")))]
> ""
> "cmp %2.L, %1.L, %0:%I0 %!"
> )
>
> I want the combiner to combine both insns since I have an intruction
> which can compare from an HI partial register.
> I am trying to write an insn pattern for that but the combiner does not use i.
> I thought about something like:
>
> (define_insn "cmprr_hi__1"
> [(set (match_operand:BI 0 "register_operand" "=c")
> (any_cond_rr:BI (zero_extract:SI (match_operand:DI 1
> "register_operand" "d")
> (const_int 16) (const_int 16))
> (match_operand:HI 2 "register_operand" "d")))]
> ""
> "cmp %2.L, %1.L, %0:%I0 %!"
> )
>
> but it does not work.
That insn won't work because you don't have a DImode operand to your
zero_extract. You have an SImode operand. It's a subeg of a DImode
operand, but that doesn't matter.
I'm not sure how well combine will work with the paradoxical subreg
(subreg:SI (reg:HI 129 [ __prephitmp_4 ]) 0) though.
Ian
Re: Is it possbile to hack I386 backend to make all function calls to be indirect function calling?
redriver jiang writes: > I meet a requirement to make all function calls to be indirect > function calling ( for I386 GCC compiler). I am not familiar with > frontend, so my first idea is > > to hack it from backend, change the asm output for "call" and > "call_value" insn patterns, generate a related varible in data > section, > > and when output call insn, output indirect call. You could probably just change the call_insn_operand predicate to not accept constant_call_address_operand. Or something along those lines. Ian
Re: movmemm pattern
On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning wrote:
> Question on movmemm:
>
> Given
>
> extern int *i, *j;
> void foo (void) { memcpy (i, j, 10); }
>
> I would expect to see argument 4 (the shared alignment) to be sizeof(int)
> since both argument are pointers to int. What I get instead is 1. Why is
> that?
Because the int * could point to unaligned data and there is no access
that would prove otherwise (memcpy accepts any alignment).
Richard.
> If I have
>
> extern int i[10], j[10];
>
> then I do get larger alignment as expected.
>
> paul
>
>
Re: REGNO_OK_FOR_BASE_P
Paul Koning writes: > Working on the pdp11 target, I ran into something odd. > > It defines REGNO_OK_FOR_BASE_P in a way that seems to match what gccint says > one should do in the "strict" case -- but does so all the time. > Specifically, it says: > > #define REGNO_OK_FOR_BASE_P(REGNO) \ > ((REGNO) < 8 || (unsigned) reg_renumber[REGNO] < 8) > > (8 because there are 8 general registers on the PDP11, all suitable as base.) > > It then defines another similarly named macro REG_OK_FOR_BASE_P which takes > an rtx instead of a regno, for use in GO_IF_LEGITIMATE_ADDRESS. That second > macro *does* come with a non-strict form which accepts all registers. > > Looking at gccint, that seemed wrong. As far as I can tell, > REG_OK_FOR_BASE_P is not (or no longer) a standard macro so it's just a > convenience macro inside the target. No problem there. But the strict > REGNO_OK_FOR_BASE_P in non-strict settings seemed like an issue, so I changed > it. > > The surprise it that it makes no difference. No change in code, no change in > testsuite results. Why didn't it matter? Is the documentation wrong? Or is > the existing definition somehow ok even for the non-strict case, in a way > that isn't obvious? I think the documentation is wrong. REGNO_OK_FOR_BASE_P is only meaningful for hard registers. It doesn't make much sense to ask whether a pseudo-register is OK to use as a base. The pseudo-register can in principle be assigned to any hard register, so the answer is always true. In older releases GO_IF_LEGITIMATE_ADDRESS was often a macro written in terms of REGNO_OK_FOR_BASE_P. Since GO_IF_LEGITIMATE_ADDRESS had to change based on REG_OK_STRICT, it made sense to have REGNO_OK_FOR_BASE_P change based on REG_OK_STRICT. But the generic part of gcc will not check REGNO_OK_FOR_BASE_P for a pseudo register. And since current targets should be using TARGET_LEGITIMATE_ADDRESS_P instead of GO_IF_LEGITIMATE_ADDRESS, the issue of REGNO_OK_FOR_BASE_P is less important. Probably the docs should be changed. Ian
Re: Is it possbile to hack I386 backend to make all function calls to be indirect function calling?
> redriver jiang writes: > > > I meet a requirement to make all function calls to be indirect > > function calling ( for I386 GCC compiler). I am not familiar with > > frontend, so my first idea is > > > > to hack it from backend, change the asm output for "call" and > > "call_value" insn patterns, generate a related varible in data > > section, > > > > and when output call insn, output indirect call. > > You could probably just change the call_insn_operand predicate to not > accept constant_call_address_operand. Or something along those lines. -mcmodel=large already promote all calls to be indirect as far as I can remember (on x86-64) but you can just grab that code for x86 too. Honza > > Ian
Re: Discussion about merging Go frontend
On 25/10/2010 19:43, Andi Kleen wrote: > Andrew Pinski writes: > >> On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor wrote: >>> At least, that is how I see it. >> Why not require libelf just like for LTO? That seems like a time to >> reduce what we depend on. For an example if we compile with lto and >> go, GCC will use two different elf libraries. This seems dumb really. > > libelf is rather awkward and has different implementations with > different bugs and also usually needs to be installed explicitely on > Linux. > > It would be better to make LTO use Ian's library (but then it's C++ I > believe, not C) > > -Andi What would be even nicer would be if we could share the same code-reader interface between lto and go (and the lto-plugin), thereby getting object format independence equally everywhere for no extra cost. That could be orthogonal to plugging elfcpp into the role currently occupied by libelf in that reader. (As to needing c++, that's just a matter of enabling c++ as a stage1 language and living with the minor limitation that go can't be a stage1 language unless you already have an installed c++ compiler, no?) cheers, DaveK
Re: Discussion about merging Go frontend
On 10/25/2010 7:01 PM, Dave Korn wrote: > What would be even nicer would be if we could share the same code-reader > interface between lto and go (and the lto-plugin), thereby getting object > format independence equally everywhere for no extra cost. > > That could be orthogonal to plugging elfcpp into the role currently occupied > by libelf in that reader. I think it's reasonable to argue that GCC should, going forward, be an ELF-only toolchain -- with postprocessing tools for generating PE/COFF, Symbian DLLs, Mach-O or what have you. But, we haven't made that decision. So, I don't think we should get there by half-measures. Either we should decide that's what we want to do, or we should try to keep the compiler independent of the object file format -- as we have up until now. I understand Ian's distaste for BFD, but it is the format-independent object file reader we have, so it seems a natural choice. And libelf, which we already rely on seems more natural than elfcpp, if we're willing to go ELF-only -- unless we're going to replace the use of libelf in LTO with elfcpp as well. In any case, I think we should avoid a single compiler build requiring multiple object-file reading libraries. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: movmemm pattern
On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote:
> On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning wrote:
>> Question on movmemm:
>>
>> Given
>>
>> extern int *i, *j;
>> void foo (void) { memcpy (i, j, 10); }
>>
>> I would expect to see argument 4 (the shared alignment) to be sizeof(int)
>> since both argument are pointers to int. What I get instead is 1. Why is
>> that?
>
> Because the int * could point to unaligned data and there is no access
> that would prove otherwise (memcpy accepts any alignment).
Ok, but if I do a load on an int*, I get an aligned load, not an unaligned
load, so in all those other cases there *is* an assumption that an int*
contains a properly aligned address.
paul
Re: movmemm pattern
On 26/10/2010 01:53, Paul Koning wrote:
> On Oct 25, 2010, at 3:44 PM, Richard Guenther wrote:
>
>> On Mon, Oct 25, 2010 at 11:26 AM, Paul Koning
>> wrote:
>>> Question on movmemm:
>>>
>>> Given
>>>
>>> extern int *i, *j; void foo (void) { memcpy (i, j, 10); }
>>>
>>> I would expect to see argument 4 (the shared alignment) to be
>>> sizeof(int) since both argument are pointers to int. What I get
>>> instead is 1. Why is that?
>> Because the int * could point to unaligned data and there is no access
>> that would prove otherwise (memcpy accepts any alignment).
>
> Ok, but if I do a load on an int*,
I think that is what Richard meant by an "access that would prove otherwise".
> I get an aligned load, not an unaligned
> load, so in all those other cases there *is* an assumption that an int*
> contains a properly aligned address.
This is a bit like GCC optimising away a null-pointer check if it knows
you've already dereferenced the pointer. Either you've already crashed by
then, or it doesn't matter.
What happens if you dereference i and j before the memcpy in foo? Do you
then get int-sized shared alignment in movmemM?
extern int *i, *j; void foo (void) { *i; *j; memcpy (i, j, 10); }
cheers,
DaveK
Re: Discussion about merging Go frontend
On 25/10/2010 23:49, Mark Mitchell wrote: > On 10/25/2010 7:01 PM, Dave Korn wrote: > >> What would be even nicer would be if we could share the same code-reader >> interface between lto and go (and the lto-plugin), thereby getting object >> format independence equally everywhere for no extra cost. >> >> That could be orthogonal to plugging elfcpp into the role currently >> occupied >> by libelf in that reader. > > I think it's reasonable to argue that GCC should, going forward, be an > ELF-only toolchain -- with postprocessing tools for generating PE/COFF, > Symbian DLLs, Mach-O or what have you. But, we haven't made that > decision. So, I don't think we should get there by half-measures. I'll probably be on the other side of that argument, when it comes, for a combination of political and engineering reasons. But, like you say, let's not get side-tracked. > Either we should decide that's what we want to do, or we should try to > keep the compiler independent of the object file format -- as we have up > until now. Ian could fairly point out that LTO was accepted into the compiler before it was format-agnostic. I would counter that, until such a decision as you contemplate is actually made, it would have been preferable if it was format-agnostic from the start. However, we are where we are, and don't want to let the perfect be the enemy of the good. > I understand Ian's distaste for BFD, but it is the > format-independent object file reader we have, so it seems a natural > choice. And libelf, which we already rely on seems more natural than > elfcpp, if we're willing to go ELF-only -- unless we're going to replace > the use of libelf in LTO with elfcpp as well. Well, TBH, I suggested BFD as a devil's-advocate position. It does indeed work, but it is kind of clunky, and top-heavy for what the compiler's requirements actually amount to. From Ian's description, gccgo has the exact same requirements as LTO: be able to parse an object file, get a list of sections, and get raw binary access to the data contained within a named section. This is a problem which we already have solved. (And indeed LTO's solution also has object writing capabilities that gccgo doesn't need.) > In any case, I think we should avoid a single compiler build requiring > multiple object-file reading libraries. Code re-use FTW! As far as I can see, we're not going to need anything significantly more complex than what the LTO-FE already needs, until and unless we get to a point of integrating the (assembler and) linker into the compiler itself, which is a long way off for now. That being the case, I think a reasonable plan would be: - integrate gccgo, with elfcpp - then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all the FEs can share it - then convert it to use elfcpp (with a bit of file I/O added) and stop using libelf altogether - then switch gccgo over to using it ... of which I think all but the first step would even be stage3-friendly. cheers, DaveK
Re: Discussion about merging Go frontend
On 10/25/2010 10:07 PM, Dave Korn wrote: > - integrate gccgo, with elfcpp > - then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all > the FEs can share it > - then convert it to use elfcpp (with a bit of file I/O added) and stop using > libelf altogether > - then switch gccgo over to using it I think that's a reasonable plan. It makes things no less object-file netural than they are now, which is OK. (And, before someone else points it out, I believe it was I who started using libelf in the LTO prototype, so I know full well how we got here!) I certainly have no problem with using elfcpp over libelf. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
Dave Korn writes: > [...] From Ian's description, gccgo has the exact same requirements > as LTO: be able to parse an object file, get a list of sections, and > get raw binary access to the data contained within a named section. > This is a problem which we already have solved. (And indeed LTO's > solution also has object writing capabilities that gccgo doesn't > need.) [...] By the way, is there some necessity in accomplishing this by means of a linked library, as opposed to via a spawned objcopy process? - FChE
Re: Discussion about merging Go frontend
On 10/25/2010 10:34 PM, Frank Ch. Eigler wrote: > By the way, is there some necessity in accomplishing this by means of > a linked library, as opposed to via a spawned objcopy process? Probably none in theory, but it certainly seems messy and likely to be slow in practice. Is there a reason that this would be desirable? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
Hi - > > By the way, is there some necessity in accomplishing this by means of > > a linked library, as opposed to via a spawned objcopy process? > Probably none in theory, but it certainly seems messy and likely to > be slow in practice. Yes, maybe. > Is there a reason that this would be desirable? It would seem to moot the present discussion about competing elf consumer libraries. "none of the above" is a possible answer. - FChE
Re: Discussion about merging Go frontend
On 10/25/2010 10:39 PM, Frank Ch. Eigler wrote: > It would seem to moot the present discussion about competing elf > consumer libraries. "none of the above" is a possible answer. True. It seems that LTO and Go need a very simple interface; presumably we can abstract that in the compiler and then we can implement that interface as we please. I agree that a fallback to an external objcopy is plausible, as is linking with BFD. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
inline assembly vs. intrinsic functions
Hi, I am trying to demonstrate my port capabilities. I am writing an application which needs to use instructions like max a,b,c,d,e,f where a,b,c are inputs and d,e,f are outputs. Is that possible to write an intrinsic function for that? I think not because that means that I need to pass d,e,f by reference which means that they would be in memory and not in a register as meant by the instruction. Is there any port with such an example? So, I thought of implementing that with inline assembly but here I encounter a different problem: The compiler does not understand the instruction given in inline assembly and therefore it does not parallelize it with other insns. Is there any other solution for that which I don't see? Thanks, Roy.
