search for: autoupgrades

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 the last few years. 3.1 added upgrade for:

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 a...

Is there a reason why? IE is it hard to maintain, 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

...ailto: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 the amount of code here continue to grow indefinitely. It's pretty poorly structured a...

>> 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

...m.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 the amount of code here continue to grow indefinitely. It's pretty poorly s...

...alf 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 the amount of code here continue to grow > indefinitely. It's pr...

On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com>wrote: > >> >> >> >> On Thu, Nov 21, 2013 at 11:45 AM, Manman Ren <manman.ren at gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Nov 21, 2013 at

On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > 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

On Fri, Nov 22, 2013 at 9:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> wrote: >> >> >> >> >> On Thu, Nov 21, 2013 at 12:01 PM, David Blaikie <dblaikie at gmail.com> >> wrote: >>> >>> >>> >>> >>> On Thu,

>> >> 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

On Fri, Nov 22, 2013 at 9:54 AM, Eric Christopher <echristo at gmail.com>wrote: > On Fri, Nov 22, 2013 at 9:08 AM, David Blaikie <dblaikie at gmail.com> wrote: > > > > > > > > On Thu, Nov 21, 2013 at 4:17 PM, Manman Ren <manman.ren at gmail.com> > wrote: > >> > >> > >> > >> > >> On Thu, Nov 21, 2013 at

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-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

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

On Mon, Nov 18, 2013 at 10: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

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal > Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> > Sent: Wednesday, February 10, 2016 6:59:50 PM > Subject: Re: [llvm-dev] [PPC] Linker fails on

Hi, TL;DR r317488 changed the way fast math flags are laid out in the bitcode and 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

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,