On Sun, Sep 30, 2018 at 1:21 PM Peter Bergner <berg...@linux.ibm.com> wrote: > > On 9/28/18 4:34 PM, Vladimir Makarov wrote: > > I remember I experimented with value numbering and using it in building > > conflicts (that time it was global.c) but it did not improve the code as > > I expected and made RA much slower. > > Yes, value numbering is not cheap to compute for catching special cases > like this that probably don't happen too often. Handling copies is fairly > cheap and easy though. > > > > We had some PRs with old RA code generation in case of using undefined > > values. > > I don't remember what problems were exactly but I remember Ken Zadeck worked > > on this too. That is why I probably chose the current scheme of conflict > > building. > > > > May be I was wrong because you testing shows that it is not a problem > > anymore. > > Maybe it was due to code relying on undefined behavior? Anyway, it'll be good > to let PATCH 1 bake on trunk for a little while before we commit PATCH 2 to > catch any (if they exist) problems related to that change. > > > > The 1st patch is ok for me. You can commit it to the trunk. > > Ok, PATCH 1 is now committed, thanks! > > > > I'll review the second patch on the next week. > > Sounds great as it gives any problems caused or exposed by PATCH 1 time to > be reported. Thanks again!
This caused: FAIL: gcc.target/i386/pr63527.c scan-assembler-not movl[ \t]%[^,]+, %ebx FAIL: gcc.target/i386/pr63534.c scan-assembler-not movl[ \t]%[^,]+, %ebx FAIL: gcc.target/i386/pr64317.c scan-assembler addl[ \\t]+[$]_GLOBAL_OFFSET_TABLE_, %ebx FAIL: gcc.target/i386/pr64317.c scan-assembler movl[ \\t]+c@GOTOFF[(]%ebx[)] for Linux/i686. -- H.J.
