search for: autoupgrad

We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics that have been replaced with native IR over the years. Has enough time and/or versions passed that we can begin phasing out some of this code? As I'm writing these we don't seem to have tests for a lot of the older upgrades. We've done better at this in t...

Many of the older autoupgrades have no test cases because I think when we upgraded them we just replace all the code in the tests with native IR. So for some of the code we don't even know if it works. I don't really want to watch the amount of code here continue to grow indefinitely. It's pretty poorly structured...

...aintain, slow, or are you just worried it will break? or something else? (I'm not opposed in any way, literally just want to understand the motivation) On Wed, Sep 20, 2017 at 12:20 PM, Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > We have quite a lot of code in AutoUpgrade.cpp to upgrade X86 intrinsics > that have been replaced with native IR over the years. Has enough time > and/or versions passed that we can begin phasing out some of this code? > > As I'm writing these we don't seem to have tests for a lot of the older > upgrades. We've...

...ic thread about backward compatibility would be appropriate. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Craig Topper via llvm-dev Sent: Wednesday, September 20, 2017 1:01 PM To: Daniel Berlin Cc: llvm-dev Subject: Re: [llvm-dev] RFC: [X86] Can we begin removing AutoUpgrade support for x86 instrinsics added in early 3.X versions Many of the older autoupgrades have no test cases because I think when we upgraded them we just replace all the code in the tests with native IR. So for some of the code we don't even know if it works. I don't really want to watch t...

>> The days of the old .ll parser are long gone, but is it too late to >> change? In case it is not, the attached patches implement just that >> :-) > I'm afraid you need to provide syntax autoupgrade until 4.0 Why, we moved to doing autoupgrade via bitcode quiet some time ago. There were quiet a few format changes to the .ll in the process. Cheers, Rafael

...From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Craig Topper via llvm-dev > Sent: Wednesday, September 20, 2017 1:01 PM > To: Daniel Berlin > Cc: llvm-dev > Subject: Re: [llvm-dev] RFC: [X86] Can we begin removing AutoUpgrade support for x86 instrinsics added in early 3.X versions > > Many of the older autoupgrades have no test cases because I think when we upgraded them we just replace all the code in the tests with native IR. So for some of the code we don't even know if it works. > > I don't...

...v [mailto:llvm-dev-bounces at lists.llvm.org > <llvm-dev-bounces at lists.llvm.org>] *On Behalf Of *Craig Topper via > llvm-dev > *Sent:* Wednesday, September 20, 2017 1:01 PM > *To:* Daniel Berlin > *Cc:* llvm-dev > *Subject:* Re: [llvm-dev] RFC: [X86] Can we begin removing AutoUpgrade > support for x86 instrinsics added in early 3.X versions > > Many of the older autoupgrades have no test cases because I think when we > upgraded them we just replace all the code in the tests with native IR. So > for some of the code we don't even know if it works. > > I...

...very client of bitcode >> loading. >> > > We can drop the debug info in the auto upgrading path similar to how we > upgrade TBAA tags. > I am going to move StripDebugInfo from StripSymbols.cpp to DebugInfo.cpp > so the implementation can be shared between StripSymbols and AutoUpgrade. > After that, a sample patch looks like: > Index: include/llvm/AutoUpgrade.h > =================================================================== > --- include/llvm/AutoUpgrade.h (revision 195264) > +++ include/llvm/AutoUpgrade.h (working copy) > @@ -57,6 +57,10 @@ > //...

...have to change one place, not every client of bitcode > loading. > We can drop the debug info in the auto upgrading path similar to how we upgrade TBAA tags. I am going to move StripDebugInfo from StripSymbols.cpp to DebugInfo.cpp so the implementation can be shared between StripSymbols and AutoUpgrade. After that, a sample patch looks like: Index: include/llvm/AutoUpgrade.h =================================================================== --- include/llvm/AutoUpgrade.h (revision 195264) +++ include/llvm/AutoUpgrade.h (working copy) @@ -57,6 +57,10 @@ /// with different address spaces: th...

...gt;>> loading. >> >> >> We can drop the debug info in the auto upgrading path similar to how we >> upgrade TBAA tags. >> I am going to move StripDebugInfo from StripSymbols.cpp to DebugInfo.cpp >> so the implementation can be shared between StripSymbols and AutoUpgrade. >> After that, a sample patch looks like: >> Index: include/llvm/AutoUpgrade.h >> =================================================================== >> --- include/llvm/AutoUpgrade.h (revision 195264) >> +++ include/llvm/AutoUpgrade.h (working copy) >> @@ -5...

>> >> At a minimum, it seems like we need a version number in the debug info >> metadata so we can detect this situation and avoid crashing. > > > Or to put it in the terms of the IR: we need to autoupgrade the debug info > metadata just like we do intrinsics. With debug info this might (at the > worst) involve dropping old metadata. > The verifier is probably the best route here. I think if we fail debug info verification we can just strip it and continue. -eric >> >> >&gt...

...> >> > >> We can drop the debug info in the auto upgrading path similar to how we > >> upgrade TBAA tags. > >> I am going to move StripDebugInfo from StripSymbols.cpp to DebugInfo.cpp > >> so the implementation can be shared between StripSymbols and > AutoUpgrade. > >> After that, a sample patch looks like: > >> Index: include/llvm/AutoUpgrade.h > >> =================================================================== > >> --- include/llvm/AutoUpgrade.h (revision 195264) > >> +++ include/llvm/AutoUpgrade.h (wor...

On Tue, Jun 9, 2009 at 2:58 PM, Nicolas Capens<nicolas at capens.net> wrote: > Please consider committing the attached patch. I believe the SSE2 packsswb, > packssdw and packuswb intrinsics have an incorrect return type. If we really wanted to do this, an AutoUpgrade patch would be necessary for backwards-compatibility. I'm not sure it's worth bothering. -Eli

Hi Eli, What exactly do mean by an AutoUpgrade patch? I don't see how this could cause any issues with backward compatibility. People currently using these intrinsics need a bitcast of the result to avoid an assert, and with the patch applied the bitcast is no longer necessary. Cheers, Nicolas -----Original Message----- From: llvmdev-...

Hi all, Please consider committing the attached patch. I believe the SSE2 packsswb, packssdw and packuswb intrinsics have an incorrect return type. Thanks, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090609/85ed0b5e/attachment.html> -------------- next part -------------- A

...:35 AM, Eric Christopher <echristo at gmail.com>wrote: > >> At a minimum, it seems like we need a version number in the debug info > >> metadata so we can detect this situation and avoid crashing. > > > > > > Or to put it in the terms of the IR: we need to autoupgrade the debug > info > > metadata just like we do intrinsics. With debug info this might (at the > > worst) involve dropping old metadata. > > > > The verifier is probably the best route here. I think if we fail debug > info verification we can just strip it and continue....

...space solution for x86. How much work > would it be to do that? Alternately: Hal, Kit, what do you two think > as far as the ppc backend? > The other solution you mentioned - combining the slot load into the > existing intrinsic might work, we'd just need to figure out how to > autoupgrade everything into it which might be a bit more difficult > than fixing the backends and dealing. Have you looked into how the > autoupgrade would work? > Thanks! > -eric > > Thanks! _______________________________________________ > > > LLVM Developers mailing list >...

...d anyone compiling a pre-llvm-6.0 bitcode with llvm-6.0 will lose all the optimizations guarded by isFast and a pre-llvm-6.0 compiler compiling a llvm-6.0 bitcode will potentially generate incorrect code w.r.t. fast math expectations. Should we bump the bitcode version because of that and have the autoupgrader properly rewrite the fast-math to preserve that semantic? (I believe we should!) * Context * With https://reviews.llvm.org/D39304 <https://reviews.llvm.org/D39304> / r317488 we got rid of the umbrella UnsafeMath flag and introduced 3 more flags that better represent the different things...

On Thu, Nov 21, 2013 at 11:45 AM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 11:26 AM, David Blaikie <dblaikie at gmail.com>wrote: > >> >> >> >> On Thu, Nov 21, 2013 at 11:06 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Nov 21, 2013 at

Hi LLVM developers, After Remove int_x86_sse2_psll_dq_bs and int_x86_sse2_psrl_dq_bs intrinsics. The builtins aren't used by clang. https://reviews.llvm.org/rL229069 there was no Intrinsic::x86_sse2_psrl_dq any more, then how to migrate: Function *F = Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse2_psrl_dq); Result = Builder.CreateCall(F,