LGTM - cheers
Fri, Sep 13
@tnorthover There are a number of EXPENSIVE_CHECKS failures due to this: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/19653/steps/test-check-all/logs/stdio
Can we easily get a constexpr test?
Accepting this to remove the block
Thu, Sep 12
Thanks - this builds cleanly on MSVC now
Wed, Sep 11
In which case I'm happy to go with this.
@alex-t This is failing on EXPENSIVE_CHECKS builds: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/19594/steps/test-check-all/logs/stdio
Tue, Sep 10
Totally missed that - thanks for noticing. I must have forgotten to remove stuff from the header since clang/gcc don't warn about it.
I'll get hold of a Windows machine soon-ish and I'll make sure to fix this problem.
Mon, Sep 9
This would make it policy for -Oz builds to not bother to break dependencies but -Os/-O0+ builds would still do.
Thanks @reames - no more comments from me.
I am providing definitions in the C++ file - the problem is that they are not available in the header before the extern declaration. The methods are available at the site of the extern definition.
gcc and clang accept this, so does Visual Studio 2019. This feels like an incorrect implementation of extern templates in Visual Studio?
I see two ways to proceed: move everything into a header (would like to avoid this) or silence the warning on VC++ (not great either).
Is there a better way? Which option is less bad from these two?
LGTM - cheers
@nand The MSVC warnings are self explanatory - you've declared a number of methods (visitIndirectMember, emitConv and getPtrConstFn) but not provided definitions, as they're on template classes MSVC complains, a lot.
We should probably mention this in the release notes
@jmolloy This is causing "compiler is out of heap space" errors on my VS2017 and VS2019 all targets builds:e:\llvm\ninja17\lib\target\hexagon\hexagongendfapacketizer.inc(4892) : fatal error C1002: compiler is out of heap space in pass 2
Slightly beyond the scope of this patch, but would it be realistic to support non-constant cases? I know at present m_Power2 can't handle this
@jmolloy This is causing "compiler is out of heap space" errors on my VS2017 and VS2019 all targets builds:
e:\llvm\ninja17\lib\target\hexagon\hexagongendfapacketizer.inc(4892) : fatal error C1002: compiler is out of heap space in pass 2
Sun, Sep 8
Sat, Sep 7
LGTM, sorry for sidetracking the patch
Makes sense to me - any one else have any comments?
Yes the vXi8 shifts for instance
Do we need to include some benchmark numbers?
Nice catch! LGTM, as @lebedev.ri suggested please pre-commit the test so when the fix is committed it shows the codegen diff.
LGTM - this could be useful!
Code coverage agrees that this is dead:
Fri, Sep 6
Thanks for the information!
We have reverted the patch and will resubmit it when we have a complete fix.
reopening until the regressions have been investigated
@courbet What's happening with this patch?
@craig.topper Is this still relevant? At least some of these changes have been fixed by improvements to SimplifyDemandedBits
rebase after D67071 has landed? (and add equivalent scale == 0 tests)
For vectors this is a big increase in constant pool usage - are we sure we want to do this?
Makes sense - LGTM
Thu, Sep 5
Worth adding a vector test ?
Also, as its x86 specific miscellaneous-builtins.c should be called x86-builtins.c (or similar).
I'm not clear on why we can't peephole replace MOVSX with CBW at a later stage.
rL371078 should fix this
Please abandon this, it isn't a valid solution to the issue (raised at PR43227). I have a WIP fix that will address this correctly.
I've raised https://bugs.llvm.org/show_bug.cgi?id=43227 to handle this
@paquette I'm sorry but I had to revert rL370996 at rL371051 to fix the EXPENSIVE_CHECKS builds: http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/19511/