Re: Scheduler:LLVM vs gcc, which is better
On Tue, Mar 11, 2014 at 11:30:28AM +0800, lin zuojian wrote: > Hi Chandler, > Thanks a lot for your answer.It is pretty misleading to find out > that DAG has schedule unit. > -- > Regards > lin zuojian Hi Chandler, I have looked into their "Machine Instr Scheduler", and find out that LLVM have not yet enable them by default.And further test find they are still not yet working.(e.g,-mtune=cortex-a9,a15,a53 generates the same code). -- Regards lin zuojian
Re: [RFC] Meta-description for tree and gimple folding
On Tue, 11 Mar 2014, Marc Glisse wrote: > On Mon, 3 Mar 2014, Richard Biener wrote: > > > > How do you handle a > > > transformation that currently tries to recursively fold something else and > > > does the main transformation only if that simplified? > > > > And doesn't do the other folding (because it's not in the IL literally?)? > > Similar to the cst without overflow case, by writing custom C code > > and allowing that to signal failure. > > Note that for this kind of simplification, it can be inconvenient to have > canonicalization included with the "real" simplifications. Imagine I am > looking at (x?3:5)+y. If 3+y "simplifies" to y+3 and 5+y "simplifies" to y+5, > then it looks worth it to replace the expression with x?y+3:(y+5). > > Would there be a convenient way to separate them, so it can tell me that 3+y > should be replaced with y+3 but that it is not a simplification? You could certainly "mark" those patterns in a special way (though the specific case, 3 + y to y + 3 will happen behind patterns back, so in this case it won't tell you that 3 + y simplifies). Note that you can't write patterns that apply "if 3 + y simplifies", at least not without doing sth as awkward as (match_and_simplify (plus (cond @0 @1 @2) @3) if (gimple_match_and_simplify (PLUS_EXPR, TREE_TYPE (@1), @1, @3, NULL, NULL) || gimple_match_and_simplify (PLUS_EXPR, TREE_TYPE (@2), @2, @3, NULL, NULL)) (cond @0 (plus @1 @3) (plus @2 @3))) that is, very much do extra work. We'd maybe want to be able to instead write (match_and_simplify (plus (cond @0 @1 @2) @3) (cond @0 (plus:simplifies_p @1 @3) (plus:simplifies_p @2 @3))) but I'm not sure how to best express whether both expressions have to simplify or only one ... (eventually only allow || here, as we should commit to use a simplification once we created it, not throw it away eventually). Or sth like (match_and_simplify (plus (cond @0 @1 @2) @3) if simplifies (plus@4 @1 @3) (cond @0 @4 (plus @2 @3)) not sure how to do || vs. && (or even two simplifies conditions) best. OTOH, I'd rather avoid adding those kind of patterns for now. There are interesting enough challenges with existing "simple" ones. Richard.
Re: Scheduler:LLVM vs gcc, which is better
On 12 March 2014 15:13, lin zuojian wrote: > Hi Chandler, > I have looked into their "Machine Instr Scheduler", and find out > that LLVM have not yet enable them by default.And further test find > they are still not yet working.(e.g,-mtune=cortex-a9,a15,a53 > generates the same code). Can I encourage you to move this thread to the LLVM list? --renato
Re: [RFC] Meta-description for tree and gimple folding
On Wed, 12 Mar 2014, Richard Biener wrote: On Tue, 11 Mar 2014, Marc Glisse wrote: On Mon, 3 Mar 2014, Richard Biener wrote: How do you handle a transformation that currently tries to recursively fold something else and does the main transformation only if that simplified? And doesn't do the other folding (because it's not in the IL literally?)? Similar to the cst without overflow case, by writing custom C code and allowing that to signal failure. Note that for this kind of simplification, it can be inconvenient to have canonicalization included with the "real" simplifications. Imagine I am looking at (x?3:5)+y. If 3+y "simplifies" to y+3 and 5+y "simplifies" to y+5, then it looks worth it to replace the expression with x?y+3:(y+5). Would there be a convenient way to separate them, so it can tell me that 3+y should be replaced with y+3 but that it is not a simplification? You could certainly "mark" those patterns in a special way (though the specific case, 3 + y to y + 3 will happen behind patterns back, so in this case it won't tell you that 3 + y simplifies). Ah, that's good, maybe what I was asking for is mostly already there :-) Note that you can't write patterns that apply "if 3 + y simplifies", at least not without doing sth as awkward as (match_and_simplify (plus (cond @0 @1 @2) @3) if (gimple_match_and_simplify (PLUS_EXPR, TREE_TYPE (@1), @1, @3, NULL, NULL) || gimple_match_and_simplify (PLUS_EXPR, TREE_TYPE (@2), @2, @3, NULL, NULL)) (cond @0 (plus @1 @3) (plus @2 @3))) I think it's ok having to write something a bit longer when doing complicated things, as long as it is doable at all. that is, very much do extra work. Ah, because the simplification of each PLUS_EXPR will be done twice? OTOH, I'd rather avoid adding those kind of patterns for now. There are interesting enough challenges with existing "simple" ones. Sure. -- Marc Glisse
Re: [RFC] Meta-description for tree and gimple folding
On Wed, 12 Mar 2014, Marc Glisse wrote: > On Wed, 12 Mar 2014, Richard Biener wrote: > > > On Tue, 11 Mar 2014, Marc Glisse wrote: > > > > > On Mon, 3 Mar 2014, Richard Biener wrote: > > > > > > > > How do you handle a > > > > > transformation that currently tries to recursively fold something else > > > > > and > > > > > does the main transformation only if that simplified? > > > > > > > > And doesn't do the other folding (because it's not in the IL > > > > literally?)? > > > > Similar to the cst without overflow case, by writing custom C code > > > > and allowing that to signal failure. > > > > > > Note that for this kind of simplification, it can be inconvenient to have > > > canonicalization included with the "real" simplifications. Imagine I am > > > looking at (x?3:5)+y. If 3+y "simplifies" to y+3 and 5+y "simplifies" to > > > y+5, > > > then it looks worth it to replace the expression with x?y+3:(y+5). > > > > > > Would there be a convenient way to separate them, so it can tell me that > > > 3+y > > > should be replaced with y+3 but that it is not a simplification? > > > > You could certainly "mark" those patterns in a special way (though > > the specific case, 3 + y to y + 3 will happen behind patterns back, > > so in this case it won't tell you that 3 + y simplifies). > > Ah, that's good, maybe what I was asking for is mostly already there :-) > > > Note that > > you can't write patterns that apply "if 3 + y simplifies", at > > least not without doing sth as awkward as > > > > (match_and_simplify > > (plus (cond @0 @1 @2) @3) > > if (gimple_match_and_simplify (PLUS_EXPR, TREE_TYPE (@1), @1, @3, NULL, > > NULL) > > || gimple_match_and_simplify (PLUS_EXPR, TREE_TYPE (@2), @2, @3, > > NULL, NULL)) > > (cond @0 (plus @1 @3) (plus @2 @3))) > > I think it's ok having to write something a bit longer when doing complicated > things, as long as it is doable at all. > > > that is, very much do extra work. > > Ah, because the simplification of each PLUS_EXPR will be done twice? Yes. > > OTOH, I'd rather avoid adding those kind of patterns for now. There > > are interesting enough challenges with existing "simple" ones. > > Sure.
Reg Alloc Problem.
Hi All, We are porting the gcc 4.8.1 to the new target and which has the pair 16 bit registers like AB or CD or EF and we modeled it in reg_class as AB,CD and DE 16 bit pair_regs and CD ,EF as 16 bit base_regs and A,B,C,D E and F as 8 bit as general_regs. We are stuck with below issues like 1)How do we modelled such that the register alloc to pick the respective base_regs i.e CD,DE instead of AB as show in the below case LD AB ,_a;//invalid instead of it should be emit LD CD ,_a LD (AB),#100; // invalid instead of it should be emit LD (CD),#100 Please note that we override the target hook like REGNO_REG_CLASS ,but still no luck here . 2)Current target enforce the restrictions on the pair register set usage for multiplication like MUL A,B or MUL C,D or MUL E,F But not MUL A,C or MUL B,C etc not across the pair_regs . Anyone can please shed some lights here ,will be appreciate and help us in the great way . Thank you for the patience ~Umesh
New .rodata section.
Hi All , We are porting gcc4.8.1 to the new target and we created the new .rodata section w.r.t flags by get_unnamed_section() . Now we need to associate the global %object data of type .word or .byte to the created .rodata section and also we need to emit the .rodata section in the asm file . Anyone can share their experice or some inputs or reference for the same will be appreciated. Thank you for the patience. ~Umesh
unwinding through signal frame on ARM
Hi, I'm using backtrace() to obtain call context by sending signals. But program segfaults if the first instruction of a function receives signal for backtrace. ARM unwinding in libgcc uses "return_address -= 2" to get the caller address. It is OK for normal function call with "bl xxx". But it cannot handle signal frame case because "return_address -= 2" may go to the preceding function. See get_eit_entry() in libgcc/unwind-arm-common.inc. Both GDB and libunwind take signal frame as a special case on ARM unwinding. Does libgcc also need to fix the case? -- Regards, Peng
Re: unwinding through signal frame on ARM
On Wed, Mar 12, 2014 at 8:33 AM, Peng Yuan wrote: > > I'm using backtrace() to obtain call context by sending signals. But > program segfaults if the first instruction of a function receives > signal for backtrace. > > ARM unwinding in libgcc uses "return_address -= 2" to get the caller > address. It is OK for normal function call with "bl xxx". But it > cannot handle signal frame case because "return_address -= 2" may go > to the preceding function. > See get_eit_entry() in libgcc/unwind-arm-common.inc. > > Both GDB and libunwind take signal frame as a special case on ARM > unwinding. Does libgcc also need to fix the case? Note that the default libgcc unwinder does support special handling of signal frames. See _Unwind_IsSignalFrame and _Unwind_SetSignalFrame and the signal_frame field of _Unwind_FrameState. The signal_frame is set by, for example, x86_64_fallback_frame_state in gcc/config/linux/linux-unwind.h. So clearly something similar can be done for ARM. My understanding is that the ARM EABI specifies the unwind info. I don't know how that would affect this idea. Ian
BUG: Bad line number in a message
Hi, this is for 4.3.3, which is a bit old, so I'm not filing a bug.
static inline void * get_resp_ptr(U32 bkade, U32 q_id)
{
blade_data_t * bd = bfr_blade_data + ssdId;
bfr_pendcmd_q_t * pcq = bd->bfrpb_ques + q_id;
blade_resp_t *res = pcq->bfrpq_resp;
return (void *)(res + pcq->bfrpq_resp_rdix);
}
I invoked this with a constant "q_id" value that was too large for the
bfrpb_ques array.
The error message indicated "array subscript is above array bounds" for the next
line. I do hope it is no longer an issue. :)
Cheers - Bruce
Completing GCC Go escape analysis in GSoC 2014
Hi, I'm a student interested in working on GCC and want to make a
proposal of GSoC 2014 on GCC Go escape analysis.
I 've read code under /gcc/testsuit/go.* the some source code of
gofrontend, and realization of escape analysis and furthermore
optimization is needed.
Right now I have come up with a small patch of escape test at the
beginning. My patch aims at test for whether escape analysis is
working. Then I want to start some small part of performance function
and write more tests for optimization. Am i on the right direction?
Thanks a lot if anyone can give me some advice.
Ray Li
package main
import(
)
var glob_var = 0
//escape;
func global1(p bool) {
if p == true {
glob_var = 987654321
}
}
//tests for escape as return
//variable v returned as the result of the current function
func escape1() int {
v := 123
return v
}
func escape1b() (int, int) {
x, y := 123, 456
return x, y//both p and q escaped
}
func escape2(p *int) int {
return *p
}
func escape2a(p, q *int) (*int, *int) {
return p, q//escaped
}
func escape2b(p, q *int) (*int, *int) {
return escape2a(p, q) //escaped
}
func escape3(p *int) *int {
q := p
if *p > 0 {
return q //p escaped
} else {
return nil
}
}
//tests for no escape
func noesc1(ptr *int) int {
return *ptr//not escape
}
func noesc2() {
var p int
q := noesc1(&p) //not escape
t := q
_ = t
}
func noesc3() {
var p int
q := escape2(&p) //not escape
_ = q
}
func noesc4() {
var p int
q := escape2(&p) //escape
glob_var = q
}
type T struct {
a, b int
}
func (t *T) foo(x int) (*T, bool) {
t.a = x
t.b = t.a + x
return t, true //escape as return
}
func f() *T {
p, _ := new(T).foo(123)
return p
}
//escape recursively
func escrecursive(p, q int) int {
if p + q > 0 {
return escrecursive(p-1, q-1)
} else {
return p * q //escape as return and also this function become recursively escape
}
}
func main() {
}
