[RFC] expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg [target/111466]

[Vineet Gupta]

On 9/29/23 05:14, Jeff Law wrote:
>
>
> On 9/28/23 21:49, Vineet Gupta wrote:
>>
>> On 9/28/23 20:17, Jeff Law wrote:
>>> I can bootstrap & regression test alpha using QEMU user mode 
>>> emulation. So we might be able to trigger something that way. It'll 
>>> take some time, but might prove fruitful. 
>>
>> That would be awesome. It's not like this this is burning or anything 
>> and one of the things in the long tail of things we need to do in 
>> this area.
> Absolutely true.  In fact, I doubt this particular quirk is all that 
> important in the extension removal space.  But we've got enough data 
> to do a bit of an experiment.  While it takes a long time to run, it 
> doesn't require any kind of regular human intervention.  Better to 
> fire it off now while it's still fresh in our minds.  If we wait a 
> week or two I'll have forgotten everything.

Just as a data-point, the SPEC QEMU icount on RISC-V with this patch 
seems promising (+ve is better, lesser icount)

Baseline        subreg promoted
                                                 note preserved   %
benchmark       workload #
500.perlbench_r 0               1222524143251   1222717055541 -0.02%
                 1               741422677286    740573609468 0.11%
                 2               694157786227    693787219643 0.05%
502.gcc_r       0               189519277112    188986824061 0.28%  <--
                 1               224763075520    224225499491 0.24%
                 2               216802546093    216426186662 0.17%
                 3               179634122120    179165923074 0.26%  <--
                 4               222757886491    222343753217 0.19%
503.bwaves_r    0               309660270217    309640234863 0.01%
                 1               488871452301    488838894844 0.01%
                 2               381243468081    381218065515 0.01%
                 3               463786236849    463756755469 0.01%
505.mcf_r       0               675010417323    675014630665 0.00%
507.cactuBSSN_r 0               2856874668987   2856874679135 0.00%
508.namd_r      0               1877527849689   1877508676900 0.00%
510.parest_r    0               3479719575579   3479104891751 0.02%
511.povray_r    0               3028749801452   3030037805612 -0.04%
519.lbm_r       0               1172421269180   1172421185445 0.00%
520.omnetpp_r   0               1014838628822   1007680353306 0.71%  <--
521.wrf_r       0               3897783090826   3897162379983 0.02%
523.xalancbmk_r 0               1062577057227   1062508198843 0.01%
525.x264_r      0               451836043634    449289002218 0.56%  <--
                 1               1761617424590   1758009904369 0.20%  <--
                 2               1686037465791   1682815274048 0.19%  <--
526.blender_r   0               1660559350538   1660534452552 0.00%
527.cam4_r      0               2141572063843   2141254936488 0.01%
531.deepsjeng_r 0               1605692153702   1603021256993 0.17%
538.imagick_r   0               3401602661013   3401602660827 0.00%
541.leela_r     0               1989286081019   1987365526160 0.10%
544.nab_r       0               1537038165879   1528865609530 0.53%  <--
548.exchange2_r 0               2050220774922   2048840906692 0.07%
549.fotonik3d_r 0               2231807908394   2231807600916 0.00%
554.roms_r      0               2612969430882   2611529873683 0.06%
557.xz_r        0               367967125022    367760820700 0.06%
                 1               961163448926    961025548415 0.01%
                 2               522156857947    521939109911 0.04%
997.specrand_fr 0               413618578       413604068 0.00%
999.specrand_ir 0               413618578       413604068 0.00%