search for: mtrofin

...ntentionally unused, so you might even be able to skip the FIXME > annotation and just do the right thing. > That's what I'm trying to avoid - there are about 30 or so such cases. What's the negative to the flag-based ideas? > On Mon, 9 Nov 2020 at 18:18, Mircea Trofin <mtrofin at google.com> wrote: > >> There's a wrinkle in this: some tests (clang ones, for instance) have >> output checks depending on the line position of the input. For example, >> they check debug info. Adding // FIXME: comments shift that. >> >> If the goal is e...

...- we make the flag an enum: true, false, and auto_inserted - we use -allow-unused-prefixes=auto_inserted for the scripts This allows easy identification, and should be easier to script without requiring more significant test by test surgery. WDYT? On Fri, Nov 6, 2020 at 7:13 AM Mircea Trofin <mtrofin at google.com> wrote: > Oh! Perfect - thanks! > > (plus, if it becomes unsupported, there's another nudge to fix :) ) > > On Fri, Nov 6, 2020 at 7:05 AM James Henderson < > jh7370.2008 at my.bristol.ac.uk> wrote: > >> I recently discovered that multi-line RU...

> On 29 Sep 2020, at 11:13, Mircea Trofin <mtrofin at google.com> wrote: > > > > On Tue, Sep 29, 2020 at 11:09 AM Daniel Sanders <daniel_l_sanders at apple.com <mailto:daniel_l_sanders at apple.com>> wrote: > Yes so long as you're including the invalid space too (IIRC it matters for DBG_VALUE in particular) the...

...t the value here is getting to the place where the default is right (so we stop the bleeding), and where the scripted cleanup can be easily audited subsequently. On Mon, Nov 9, 2020 at 2:22 PM David Blaikie <dblaikie at gmail.com> wrote: > On Mon, Nov 9, 2020 at 2:06 PM Mircea Trofin <mtrofin at google.com> wrote: > > > > > > > > On Mon, Nov 9, 2020 at 1:54 PM David Blaikie <dblaikie at gmail.com> wrote: > >> > >> On Mon, Nov 9, 2020 at 10:18 AM Mircea Trofin via llvm-dev > >> <llvm-dev at lists.llvm.org> wrote: > >...

...er (why might not've seen this discussion > or seen the flag before) that this was added automatically and there's > a good chance the use of this feature is probably more likely than not > unintentional/in need of cleanup. > > On Mon, Nov 9, 2020 at 3:48 PM Mircea Trofin <mtrofin at google.com> wrote: > > > > My preference would be to go with the tri-value option - I think the > downside of folks needing to write a value after "-allow-unused-prefixes" > is not that terrible; if folks feel that using true/false/auto is weird, > how about &qu...

...t don't have great ideas for what that'd be. > > "-allow-unused-prefixes=allowed_by_cleanup_please_check_if_usage_is_intentional" > or something. > Right, or a separate flag dedicated to this. > > > > > On Fri, Nov 6, 2020 at 7:13 AM Mircea Trofin <mtrofin at google.com> wrote: > >> > >> Oh! Perfect - thanks! > >> > >> (plus, if it becomes unsupported, there's another nudge to fix :) ) > >> > >> On Fri, Nov 6, 2020 at 7:05 AM James Henderson < > jh7370.2008 at my.bristol.ac.uk> wro...

On Thu, Nov 5, 2020 at 11:36 AM David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Nov 5, 2020 at 10:46 AM Mircea Trofin <mtrofin at google.com> wrote: >> >> >> >> On Thu, Nov 5, 2020 at 10:40 AM David Blaikie <dblaikie at gmail.com> wrote: >>> >>> >>> >>> On Thu, Nov 5, 2020 at 7:30 AM Mircea Trofin via llvm-dev <llvm-dev at lists.llvm.org> wrote: &gt...

...eck something # RUN: --option2 And you'd end up with "some command --option1 --option2" being run. It's rather surprising behaviour, and not one I'd generally recommend exercising, but maybe in this context it would be okay? On Fri, 6 Nov 2020 at 15:00, Mircea Trofin <mtrofin at google.com> wrote: > > > On Fri, Nov 6, 2020 at 2:22 AM James Henderson < > jh7370.2008 at my.bristol.ac.uk> wrote: > >> I think it would make more sense to add it at each individual call site. >> This ensures that all cases are fixed, rather than just one in...

...if it takes a couple of weeks or a month for somebody to get it sorted, so be it (I had to get changes made a couple of years ago to an internal code base sprawled across dozens of different teams, and it took months for all the changes to get made!) On Tue, 10 Nov 2020 at 14:32, Mircea Trofin <mtrofin at google.com> wrote: > > > On Tue, Nov 10, 2020, 01:03 James Henderson <jh7370.2008 at my.bristol.ac.uk> > wrote: > >> I don't know if lit's parser is up to this (I suspect it isn't), but >> could you add a comment to the end/in the middle of a RUN?...

...clear to the casual reader (why might not've seen this discussion or seen the flag before) that this was added automatically and there's a good chance the use of this feature is probably more likely than not unintentional/in need of cleanup. On Mon, Nov 9, 2020 at 3:48 PM Mircea Trofin <mtrofin at google.com> wrote: > > My preference would be to go with the tri-value option - I think the downside of folks needing to write a value after "-allow-unused-prefixes" is not that terrible; if folks feel that using true/false/auto is weird, how about "allowed/disallowed/scr...

...ed/intentionally added > by a human. Something like "// FIXME: Verify that unused prefixes are used > intentionally" or the like. > Ack. or, we can grep for -allow-unused-prefixes=true, wdyt? > > >> >> >> On Fri, Oct 30, 2020 at 12:48 PM Mircea Trofin <mtrofin at google.com> >> wrote: >> >>> An update: as of 871d658c9ceb, the flag is now available, if folks need >>> to use it. >>> >>> On Thu, Oct 29, 2020 at 10:28 AM Mircea Trofin <mtrofin at google.com> >>> wrote: >>> >>&gt...

...39;t do that is that there's a lot more ctors than consumers of MCRegister. It seemed cheaper to do the checks when they're consumed and pretty much every consumer I encountered started with `assert(Reg.isPhysicalRegister() && ...)`. > On 29 Sep 2020, at 11:02, Mircea Trofin <mtrofin at google.com> wrote: > > Thanks! To test my understanding - we could add asserts in MCRegister ctor that the value of the unsigned is, indeed, only in the physical register namespace, is that correct? > > On Tue, Sep 29, 2020 at 10:49 AM Daniel Sanders <daniel_l_sanders at appl...

...as you go (i.e. change the expected line number, if they're not huge in number). It may be obvious from reading whether or not the prefix is intentionally unused, so you might even be able to skip the FIXME annotation and just do the right thing. On Mon, 9 Nov 2020 at 18:18, Mircea Trofin <mtrofin at google.com> wrote: > There's a wrinkle in this: some tests (clang ones, for instance) have > output checks depending on the line position of the input. For example, > they check debug info. Adding // FIXME: comments shift that. > > If the goal is easy identification of au...

...9;ve seen this discussion >> or seen the flag before) that this was added automatically and there's >> a good chance the use of this feature is probably more likely than not >> unintentional/in need of cleanup. >> >> On Mon, Nov 9, 2020 at 3:48 PM Mircea Trofin <mtrofin at google.com> wrote: >> > >> > My preference would be to go with the tri-value option - I think the downside of folks needing to write a value after "-allow-unused-prefixes" is not that terrible; if folks feel that using true/false/auto is weird, how about "allo...

On Mon, Nov 9, 2020 at 2:06 PM Mircea Trofin <mtrofin at google.com> wrote: > > > > On Mon, Nov 9, 2020 at 1:54 PM David Blaikie <dblaikie at gmail.com> wrote: >> >> On Mon, Nov 9, 2020 at 10:18 AM Mircea Trofin via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > >> > There's a wr...

..., 2020 at 11:50 AM Fāng-ruì Sòng <maskray at google.com> wrote: > >> On Thu, Nov 5, 2020 at 11:36 AM David Blaikie via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > >> > >> > >> > On Thu, Nov 5, 2020 at 10:46 AM Mircea Trofin <mtrofin at google.com> >> wrote: >> >> >> >> >> >> >> >> On Thu, Nov 5, 2020 at 10:40 AM David Blaikie <dblaikie at gmail.com> >> wrote: >> >>> >> >>> >> >>> >> >>> On Thu, Nov 5...

...m to be the larger areas there. If you see an area you have ownership or expertise in, please sign up for fixing the tests by Monday, Nov. 9. Otherwise, I will "blanket-add" --allow-unused-prefixes=true to the remaining failing tests. On Fri, Oct 30, 2020 at 12:48 PM Mircea Trofin <mtrofin at google.com> wrote: > An update: as of 871d658c9ceb, the flag is now available, if folks need to > use it. > > On Thu, Oct 29, 2020 at 10:28 AM Mircea Trofin <mtrofin at google.com> wrote: > >> Hello all, >> >> TL;DR; if you used FileCheck --check-prefix...

...in favor, but plausible - I'd probably use a long/fairly explanatory name, but don't have great ideas for what that'd be. "-allow-unused-prefixes=allowed_by_cleanup_please_check_if_usage_is_intentional" or something. > > On Fri, Nov 6, 2020 at 7:13 AM Mircea Trofin <mtrofin at google.com> wrote: >> >> Oh! Perfect - thanks! >> >> (plus, if it becomes unsupported, there's another nudge to fix :) ) >> >> On Fri, Nov 6, 2020 at 7:05 AM James Henderson <jh7370.2008 at my.bristol.ac.uk> wrote: >>> >>> I rece...

...PM, Reid Kleckner wrote: > I think lib/Transforms/Scalar/MemCpyOptimizer.cpp might be the right > place for this, considering that most frontends will use memcpy for > that copy anyway. It already has some logic for byval args. > > On Thu, Mar 5, 2015 at 3:51 PM, Mircea Trofin <mtrofin at google.com > <mailto:mtrofin at google.com>> wrote: > > Hello all, > > I'm trying to find the pass that would convert from: > > define void @main(%struct* byval %ptr) { > %val = load %struct* %ptr > %val.ptr = alloca %struct >...

errata: I am on 3.6 full stop. I *thought* there was a 3.7 available, based on the title of http://llvm.org/docs/ ("LLVM 3.7 documentation"). I suppose the docs are ahead of the release schedule? On Sun, Mar 8, 2015 at 9:44 AM Mircea Trofin <mtrofin at google.com> wrote: > Sorry, that phase is part of the PNaCl toolchain. This would be LLVM 3.6, > would your comments still apply? > > I tried -O3 to no avail. I suppose I'll get llvm 3.7, see if I can > optimize the latest snippet there (the one avoiding load/store), and s...