|
From: Konstantin S. <kon...@gm...> - 2010-04-21 15:59:14
|
Hi, Currently, IRSB may contain a loop (e.g. a loop from a memcpy-like function will be translated into one IRSB). Is there a way to force valgrind to create only acyclic IRSBs? Why: I am doing an optimization in ThreadSanitizer which requires to know (during instrumentation) the maximal number of memory accesses in a given IRSB. Thanks, --kcc |
|
From: Julian S. <js...@ac...> - 2010-04-27 12:48:10
|
You can disable loop unrolling using --vex-iropt-unroll-thresh=0, and there is an equivalent way to do it programmatically -- I think callgrind disables unrolling at startup. But in any case I don't think I understand the question. If you want to know the maximal number of accesses from a given IRSB, just count them (by looking at all the IRStmts inside it). Loop unrolling or chasing across bb boundaries (it follows calls and jumps to unknown destinations by default) should not have any effect. An IRSB that is "unrolled" is not turned into a loop that runs "within the IRSB", it is just that the IRSB is made to contain 2, 4 or 8 copies of the loop body. You can still get an upper bound of the number of memory accesses just from instrumentation-time examination. Does that make sense? (Maybe I didn't understand your question right.) J On Wednesday 21 April 2010, Konstantin Serebryany wrote: > Hi, > Currently, IRSB may contain a loop (e.g. a loop from a memcpy-like function > will be translated into one IRSB). > Is there a way to force valgrind to create only acyclic IRSBs? > > Why: I am doing an optimization in ThreadSanitizer which requires to know > (during instrumentation) the maximal number of memory accesses in a given > IRSB. > > Thanks, > > --kcc |
|
From: Konstantin S. <kon...@gm...> - 2010-04-27 15:13:21
|
Below is a dump of IRSB.
Just look at these statements:
------ IMark(0x4C1C3A4, 4) ------
...
if (t20) goto {Boring} 0x4C1C3B4:I64
goto {Boring} 0x4C1C3A4:I64
As you can see, this IRSB represents a loop (label 0x4C1C3A4).
I want valgrind to never create such IRSBs with a loop (but instead break
them into several SBs).
Is that possible?
--kcc
IRSB {
t0:I64 t1:I64 t2:I64 t3:I64 t4:I64 t5:I64 t6:I64 t7:I64
t8:I64 t9:I64 t10:I64 t11:I64 t12:I64 t13:I32 t14:I8
t15:I64
t16:I64 t17:I64 t18:I64 t19:I8 t20:I1 t21:I64 t22:I64
t23:I64
t24:I64 t25:I64 t26:I32 t27:I64 t28:I64 t29:I1 t30:I1
------ IMark(0x4C1C3A4, 4) ------
t10 = GET:I64(8)
t11 = GET:I64(48)
t8 = Add64(t11,t10)
t14 = LDle:I8(t8)
t26 = 8Uto32(t14)
t13 = t26
t27 = 32Uto64(t13)
t12 = t27
PUT(0) = t12
------ IMark(0x4C1C3A8, 3) ------
PUT(168) = 0x4C1C3A8:I64
t18 = GET:I64(56)
t15 = Add64(t18,t10)
t19 = GET:I8(0)
STle(t15) = t19
------ IMark(0x4C1C3AB, 4) ------
t2 = Add64(t10,0x1:I64)
PUT(8) = t2
------ IMark(0x4C1C3AF, 3) ------
t7 = GET:I64(16)
IR-NoOp
PUT(128) = 0x8:I64
PUT(136) = t7
PUT(144) = t2
------ IMark(0x4C1C3B2, 2) ------
PUT(168) = 0x4C1C3B2:I64
IR-NoOp
t29 = CmpLE64U(t7,t2)
t28 = 1Uto64(t29)
t25 = t28
t30 = 64to1(t25)
t20 = t30
if (t20) goto {Boring} 0x4C1C3B4:I64
goto {Boring} 0x4C1C3A4:I64
}
On Tue, Apr 27, 2010 at 5:03 PM, Julian Seward <js...@ac...> wrote:
>
> You can disable loop unrolling using --vex-iropt-unroll-thresh=0,
> and there is an equivalent way to do it programmatically -- I think
> callgrind disables unrolling at startup.
>
> But in any case I don't think I understand the question. If you want
> to know the maximal number of accesses from a given IRSB, just count
> them (by looking at all the IRStmts inside it). Loop unrolling or
> chasing across bb boundaries (it follows calls and jumps to unknown
> destinations by default) should not have any effect. An IRSB that
> is "unrolled" is not turned into a loop that runs "within the IRSB",
> it is just that the IRSB is made to contain 2, 4 or 8 copies of the
> loop body. You can still get an upper bound of the number of memory
> accesses just from instrumentation-time examination.
>
> Does that make sense? (Maybe I didn't understand your question right.)
>
> J
>
> On Wednesday 21 April 2010, Konstantin Serebryany wrote:
> > Hi,
> > Currently, IRSB may contain a loop (e.g. a loop from a memcpy-like
> function
> > will be translated into one IRSB).
> > Is there a way to force valgrind to create only acyclic IRSBs?
> >
> > Why: I am doing an optimization in ThreadSanitizer which requires to know
> > (during instrumentation) the maximal number of memory accesses in a given
> > IRSB.
> >
> > Thanks,
> >
> > --kcc
>
>
>
|
|
From: Julian S. <js...@ac...> - 2010-04-27 15:30:22
|
On Tuesday 27 April 2010, Konstantin Serebryany wrote:
> Below is a dump of IRSB.
> Just look at these statements:
> ------ IMark(0x4C1C3A4, 4) ------
> ...
> if (t20) goto {Boring} 0x4C1C3B4:I64
> goto {Boring} 0x4C1C3A4:I64
>
> As you can see, this IRSB represents a loop (label 0x4C1C3A4).
Yes.
> I want valgrind to never create such IRSBs with a loop (but instead break
> them into several SBs).
> Is that possible?
Uh .. I'm still confused. Mostly because I can't see how you can
guarantee to avoid making IRSBs which have a conditional branch
back to the start. For example, consider the translation of
"rep movsb"; we have to create a straight line block of IR which
jumps back to the start.
Can you show an IR example which illustrates what you mean?
eg, what does the IR that you want look like, for this example?
J
|
|
From: Konstantin S. <kon...@gm...> - 2010-04-27 16:39:06
|
On Tue, Apr 27, 2010 at 7:46 PM, Julian Seward <js...@ac...> wrote:
> On Tuesday 27 April 2010, Konstantin Serebryany wrote:
>> Below is a dump of IRSB.
>> Just look at these statements:
>> ------ IMark(0x4C1C3A4, 4) ------
>> ...
>> if (t20) goto {Boring} 0x4C1C3B4:I64
>> goto {Boring} 0x4C1C3A4:I64
>>
>> As you can see, this IRSB represents a loop (label 0x4C1C3A4).
>
> Yes.
>
>> I want valgrind to never create such IRSBs with a loop (but instead break
>> them into several SBs).
>> Is that possible?
>
> Uh .. I'm still confused. Mostly because I can't see how you can
> guarantee to avoid making IRSBs which have a conditional branch
> back to the start. For example, consider the translation of
> "rep movsb"; we have to create a straight line block of IR which
> jumps back to the start.
>
> Can you show an IR example which illustrates what you mean?
> eg, what does the IR that you want look like, for this example?
Consider an SB which looks like this:
BB1:
L:
code;
goto L;
Can valgrind create two SBs for this case?
BB1:
L:
code;
goto L1
BB2:
L1:
goto L
--kcc
>
> J
>
|
|
From: Konstantin S. <kon...@gm...> - 2010-04-27 17:27:05
|
In case you are curious: with PIN we rely on the fact that SBs are acyclic and it helps a lot. I've described the details here: http://code.google.com/p/data-race-test/wiki/ThreadSanitizerAlgorithm#Instrumentation:_TRACEs --kcc On Tue, Apr 27, 2010 at 8:38 PM, Konstantin Serebryany <kon...@gm...> wrote: > On Tue, Apr 27, 2010 at 7:46 PM, Julian Seward <js...@ac...> wrote: >> On Tuesday 27 April 2010, Konstantin Serebryany wrote: >>> Below is a dump of IRSB. >>> Just look at these statements: >>> ------ IMark(0x4C1C3A4, 4) ------ >>> ... >>> if (t20) goto {Boring} 0x4C1C3B4:I64 >>> goto {Boring} 0x4C1C3A4:I64 >>> >>> As you can see, this IRSB represents a loop (label 0x4C1C3A4). >> >> Yes. >> >>> I want valgrind to never create such IRSBs with a loop (but instead break >>> them into several SBs). >>> Is that possible? >> >> Uh .. I'm still confused. Mostly because I can't see how you can >> guarantee to avoid making IRSBs which have a conditional branch >> back to the start. For example, consider the translation of >> "rep movsb"; we have to create a straight line block of IR which >> jumps back to the start. >> >> Can you show an IR example which illustrates what you mean? >> eg, what does the IR that you want look like, for this example? > > > Consider an SB which looks like this: > > BB1: > L: > code; > goto L; > > Can valgrind create two SBs for this case? > BB1: > L: > code; > goto L1 > > BB2: > L1: > goto L > > > --kcc > >> >> J >> > |
|
From: Julian S. <js...@ac...> - 2010-04-28 06:11:45
|
> > Can you show an IR example which illustrates what you mean? > > eg, what does the IR that you want look like, for this example? > > Consider an SB which looks like this: > > BB1: > L: > code; > goto L; > > Can valgrind create two SBs for this case? > BB1: > L: > code; > goto L1 > > BB2: > L1: > goto L No, I don't think it will do that exactly. It will do tail duplication though: if you have (original insns) like this A; B; C; D; E then a guest branch to A will cause an IRSB for the sequence "A; B; C; D; E" to be made. If later there is a jump to C then a new sequence "C; D; E" is made, so the tail is duplicated. I imagine Pin etc will do the same. J |
|
From: Konstantin S. <kon...@gm...> - 2010-04-28 06:31:53
|
On Wed, Apr 28, 2010 at 10:27 AM, Julian Seward <js...@ac...> wrote: > > > > Can you show an IR example which illustrates what you mean? > > > eg, what does the IR that you want look like, for this example? > > > > Consider an SB which looks like this: > > > > BB1: > > L: > > code; > > goto L; > > > > Can valgrind create two SBs for this case? > > BB1: > > L: > > code; > > goto L1 > > > > BB2: > > L1: > > goto L > > No, I don't think it will do that exactly. Yes, it won't do it now. Is it possible to change V so that it does? > It will do tail duplication > though: if you have (original insns) like this > > A; B; C; D; E > > then a guest branch to A will cause an IRSB for the sequence "A; B; C; D; > E" > to be made. If later there is a jump to C then a new sequence "C; D; E" is > made, so the tail is duplicated. I imagine Pin etc will do the same. > Yes, sure. > > J > --kcc |
|
From: Julian S. <js...@ac...> - 2010-04-28 07:05:00
|
On Wednesday 28 April 2010, Konstantin Serebryany wrote: > On Wed, Apr 28, 2010 at 10:27 AM, Julian Seward <js...@ac...> wrote: > > > > Can you show an IR example which illustrates what you mean? > > > > eg, what does the IR that you want look like, for this example? > > > > > > Consider an SB which looks like this: > > > > > > BB1: > > > L: > > > code; > > > goto L; > > > > > > Can valgrind create two SBs for this case? > > > BB1: > > > L: > > > code; > > > goto L1 > > > > > > BB2: > > > L1: > > > goto L > > > > No, I don't think it will do that exactly. > > Yes, it won't do it now. > Is it possible to change V so that it does? Uh, you mean you want some functionality like that to be added? In general (to try to answer the original question), in the general case an IRSB can contain IR for guest insns with the following characteristics: * between 1 and 50 guest instructions; longer IRSBs are truncated * from up to 3 contiguous address ranges (it will chase over jumps/calls) * each guest insn may appear more than once, if the IRSB is unrolled * with --vex-guest-chase-cond=yes, it will chase also across conditional branches; this again may cause guest insns to appear more than once * in all cases, the IR for each insn is starts with an IRStmt_IMark, so by examining those you can find out exactly what is going on J |
|
From: Konstantin S. <kon...@gm...> - 2010-04-28 07:09:28
|
On Wed, Apr 28, 2010 at 11:20 AM, Julian Seward <js...@ac...> wrote: > On Wednesday 28 April 2010, Konstantin Serebryany wrote: > > On Wed, Apr 28, 2010 at 10:27 AM, Julian Seward <js...@ac...> wrote: > > > > > Can you show an IR example which illustrates what you mean? > > > > > eg, what does the IR that you want look like, for this example? > > > > > > > > Consider an SB which looks like this: > > > > > > > > BB1: > > > > L: > > > > code; > > > > goto L; > > > > > > > > Can valgrind create two SBs for this case? > > > > BB1: > > > > L: > > > > code; > > > > goto L1 > > > > > > > > BB2: > > > > L1: > > > > goto L > > > > > > No, I don't think it will do that exactly. > > > > Yes, it won't do it now. > > Is it possible to change V so that it does? > > Uh, you mean you want some functionality like that to be added? > Yep. > > In general (to try to answer the original question), in the general > case an IRSB can contain IR for guest insns with the following > characteristics: > > * between 1 and 50 guest instructions; longer IRSBs are truncated > > * from up to 3 contiguous address ranges (it will chase over jumps/calls) > > * each guest insn may appear more than once, if the IRSB is unrolled > > * with --vex-guest-chase-cond=yes, it will chase also across > conditional branches; this again may cause guest insns to appear > more than once > > * in all cases, the IR for each insn is starts with an IRStmt_IMark, > so by examining those you can find out exactly what is going on > > J > |