You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(14) |
2
(16) |
3
(13) |
4
(3) |
|
5
(18) |
6
(1) |
7
(6) |
8
(2) |
9
(16) |
10
(19) |
11
(14) |
|
12
(1) |
13
(6) |
14
(20) |
15
(26) |
16
(18) |
17
(15) |
18
(16) |
|
19
(7) |
20
(8) |
21
(19) |
22
(19) |
23
(21) |
24
(15) |
25
(15) |
|
26
(11) |
27
(17) |
28
(21) |
29
(14) |
|
|
|
|
From: Florian K. <br...@ac...> - 2012-02-07 23:13:06
|
On 02/07/2012 05:26 PM, Julian Seward wrote:
>
> Looks good. A couple of comments:
>
> + case Iex_Get:
> + case Iex_Load:
> + /* Guest state / memory could have changed in the meantime. */
> + return False;
> vs
> default:
>
> }
> +
> + return False;
>
> case Iex_GetI also fetches guest state. It will be handled by the
> default case, but to make the commenty bit more complete, could you
> pls add it alongside case Iex_Get and Iex_Load.
>
Yes, good point. Will do.
>
> + case Iex_Const: {
> + IRConst *c1 = e1->Iex.Const.con;
> + IRConst *c2 = e2->Iex.Const.con;
> + vassert(c1->tag == c2->tag);
>
> What makes this assertion true? I think it must be that e1 and e2
> always have the same type. But is that always true? Could we ever
> end up comparing constants of different types? /me thinks not, but
> is not sure.
>
I don't think that assertion can ever be true. Hey, but if you're not
sure, then it should definitely be there :)
> Final q is the effect on performance of the jit, which is already
> way to slow for its own good. Am somewhat concerned about the possibility
> of spending a lot of time in some pathological case, chasing very deep
> expression trees. I guess most trees lead pretty quickly to a Load
> or Get, in which case it stops, so maybe it's not so bad.
When I was debugging this I saw trees with 5 levels and the leaves were
all IRTemps. That does suggest it could get worse.
I want to do some more runs for performance and also to see what this
buys us in terms of saved instructions. Clearly, it won't be earth
shattering, but I'm a still curious...
> Still, maybe
> we ought to put in a simple recursion depth check that stops it going
> nuts in the worst case.
Yeah, we should do that.. I was planning to use a fixed depth across all
iropt levels. If you'd like something more fancy (command line flag to
specify the depth, different settings for different optim levels), let
me know.
Florian
|
|
From: Julian S. <js...@ac...> - 2012-02-07 22:33:34
|
> > I'd suggest that you limit sameIRExpr to recursing only over
> > Un/Bin/Tri/QuadOps, constants and IRTemps, and simply give up
> > on anything else.
>
> Yep. That is what the attached patch does. Regtested on x86_64 and s390x.
Looks good. A couple of comments:
+ case Iex_Get:
+ case Iex_Load:
+ /* Guest state / memory could have changed in the meantime. */
+ return False;
vs
default:
}
+
+ return False;
case Iex_GetI also fetches guest state. It will be handled by the
default case, but to make the commenty bit more complete, could you
pls add it alongside case Iex_Get and Iex_Load.
+ case Iex_Const: {
+ IRConst *c1 = e1->Iex.Const.con;
+ IRConst *c2 = e2->Iex.Const.con;
+ vassert(c1->tag == c2->tag);
What makes this assertion true? I think it must be that e1 and e2
always have the same type. But is that always true? Could we ever
end up comparing constants of different types? /me thinks not, but
is not sure.
Final q is the effect on performance of the jit, which is already
way to slow for its own good. Am somewhat concerned about the possibility
of spending a lot of time in some pathological case, chasing very deep
expression trees. I guess most trees lead pretty quickly to a Load
or Get, in which case it stops, so maybe it's not so bad. Still, maybe
we ought to put in a simple recursion depth check that stops it going
nuts in the worst case.
J
|
|
From: Florian K. <br...@ac...> - 2012-02-07 15:24:03
|
On 02/07/2012 06:26 AM, Julian Seward wrote: > >> Consider this: >> >> PUT(0) = 0xF:I64 >> t1 = GET:I64(0) >> PUT(4) = 0x1E:I32 >> t2 = GET:I64(0) >> t3 = And64(t2,t1) >> >> sameIRExpr(t2,t1) will return true. But the computed values are >> different. Salvaging this will be more difficult, as guest state access >> is not in SSA. > > Yeah, you have a partial overlap on the Puts and Gets. > > I'd suggest that you limit sameIRExpr to recursing only over > Un/Bin/Tri/QuadOps, constants and IRTemps, and simply give up > on anything else. Yep. That is what the attached patch does. Regtested on x86_64 and s390x. > Come to think of it, iropt also contains a CSE pass (completely > unrelated to the constant folder) which must also deal with this > same equivalance-detection problem. You might like to have a look > at it. I'm sure it uses the same give-up-if-we're-not-sure > hac^H^H^Hstrategy. It would also possibly have solved this > entire problem a different way (if we CSEd before folding) > but is mostly not used, because it is expensive. If you > want even more fun IR optimisation hacking you could rewrite > it to be much faster :-) Well... I've stared a lot at before/after optimization IR and it looks impressive. Beating that won't be easy. Florian |
|
From: Julian S. <js...@ac...> - 2012-02-07 11:32:55
|
> Consider this: > > PUT(0) = 0xF:I64 > t1 = GET:I64(0) > PUT(4) = 0x1E:I32 > t2 = GET:I64(0) > t3 = And64(t2,t1) > > sameIRExpr(t2,t1) will return true. But the computed values are > different. Salvaging this will be more difficult, as guest state access > is not in SSA. Yeah, you have a partial overlap on the Puts and Gets. I'd suggest that you limit sameIRExpr to recursing only over Un/Bin/Tri/QuadOps, constants and IRTemps, and simply give up on anything else. That will solve the original false positive problem and should be safe for the example above, since it will never conclude that two Gets produce the same value. Similarly it avoids us having to deal with complexities of equal-value proofs in the presence of loads, stores and dirty helpers. IR transformation passes that happen before constant folding include Put-to-Get forwarding (that handles the above overlap cases safely), so such a limitation for sameIRExpr is not as bad as it might at first sound. Come to think of it, iropt also contains a CSE pass (completely unrelated to the constant folder) which must also deal with this same equivalance-detection problem. You might like to have a look at it. I'm sure it uses the same give-up-if-we're-not-sure hac^H^H^Hstrategy. It would also possibly have solved this entire problem a different way (if we CSEd before folding) but is mostly not used, because it is expensive. If you want even more fun IR optimisation hacking you could rewrite it to be much faster :-) J |
|
From: Julian S. <js...@ac...> - 2012-02-07 10:43:17
|
> The good news is that the memcheck errors for bug287260.c are no > longer reported. The bad news is that there are 8 segfaults when > running make regtest on x86_64. I've been chasing the bug for a > while and stared at the patch. But it's elusive and I haven't found > it. Time for a 2nd opinion. > > The symptom for the bug is a segfault in the jitted code when > attempting to load from some address. I looked at the IRSB where it > happens and made sure that the optimization of that IRSB is correct. > So it happens somewhere earlier. Following this path looks like a > tremendous time sink... Yes .. if the state of the simulated machine got corrupted in some earlier block, your chances of finding it directly are close to zero. Without having thought about this much .. are you 110% sure there is no way your patche can move loads past stores or dirty helpers, or move gets (including GetI) past puts (including PutI), in either direction ? That kind of thing has caught me out in the past. J |
|
From: Florian K. <br...@ac...> - 2012-02-07 04:26:37
|
On 02/05/2012 11:33 AM, Florian Krohm wrote:
> On 02/01/2012 05:08 AM, Julian Seward wrote:
>>
>>
>> This is a flattened version of the expression that Florian's patch aims to
>> find. But the entire compilation pipeline operates on flattened IR -- the
>> tree building stage is (almost) the last stage, and is only there so that
>> the instruction selectors have the opportunity to convert multiple expression
>> nodes into single instructions if they want.
>>
>
> [snip]
>
>> This should be fixed in the IR optimiser, though, not in the front ends,
>> since doing it in the front ends means duplicating functionality.
>>
>
> So here is a work-in-progress patch for the IR optimizer.
>
Consider this:
PUT(0) = 0xF:I64
t1 = GET:I64(0)
PUT(4) = 0x1E:I32
t2 = GET:I64(0)
t3 = And64(t2,t1)
sameIRExpr(t2,t1) will return true. But the computed values are
different. Salvaging this will be more difficult, as guest state access
is not in SSA.
I looked at a failing example and the above scenario is indeed
happening.
Florian
|