similar to: Committing with git

> At the dev meeting I heard Doug Gregor say something like, "what kind of dirty animals are you, you just push directly to master!?" Based on that, I think other communities may set up workflows where they push branches to places, and some automation rebases and updates master asynchronously, optionally conditioned on some (light) testing or approval. Someone has already mentioned

On 18/11/2020 17:36, Mike Edwards via llvm-dev wrote: > Hi Keith, > You should be able to access the notes here: > https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing > <https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing> > Let me know if you run into any issues. Thanks. There's

Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> writes: > Weak -1 in general.  I'm not strongly opposed, but I see very little > value in this migration and a lot of headache.  Others have explained > this well, so I'll mostly skip that.  I particular dislike the assumed > fork model; I work in patches, so that's a ton of overhead process wise.  Can you

Philip Reames <listmail at philipreames.com> writes: > Let's say I post a patch, and the (warranted) reviewer comment is that > it should be split.  I push a couple new PRs, they get approved, and > landed.  (All as new branches off master.)  Then, I have a stale branch > (say it contains 2 commits) which needs rewritten.  I can of course do > an interactive rebase, and a

I'm not sure if this helps, but here it is in case it does. I typically use bugpoint in a way as to keep the actual failure that I'm after. For example, with the test case you've pasted, I was looking for a specific assert. So I used bugpoint this way: $ cat reduceme.sh #!/bin/bash llc -filetype=obj $1 2>&1 | grep 'Cannot lower calls with arbitrary operand bundles'

On 2019-10-29 01:21, Reid Kleckner via llvm-dev wrote: > At the dev meeting I heard Doug Gregor say something like, "what kind of > dirty animals are you, you just push directly to master!?" Based on > that, I think other communities may set up workflows where they push > branches to places, and some automation rebases and updates master > asynchronously, optionally

Valentin, in terms of limitations as Sean pointed out, an important one is that .mir doesn't have MachineFunctionInfo which may result in failure on accesses to global variables due to use of register X2. The verifier considers it an undefined register. Also, it's probably easier to reduce test cases using bugpoint starting from an IR test case. With the code you provided, I get a

I don't intend to weigh in on either side, but just give a perspective on a few questions asked. >From an outsiders perspective, that list isn't what I'd typically describe as the workflow, since it makes "fork" and "branch" sound like difficult operations. This sounds akin to thinking that someone would reclone the svn repo before working on a new

I think that it's really important that we try to strike some balance here. Based on my experience, this thread, and offline conversations, two things seem clear to me: 1. Overall, Phabricator is a superior tool for managing code reviews and some related processes (although GitHub's tools certainly have some benefits, and both are getting better over time). 2. Not accepting GitHub PRs

Hi, everyone, I'm currently the code owner for the PowerPC target. I worked on the PowerPC target for many years, and that was a lot of fun, but I've not been directly involved in development for PowerPC for some time. I would like to nominate Nemanja Ivanovic for the role of PowerPC target code owner. Insofar as a code owner is responsible for making sure that patches are reviewed,

In our fork of LLVM we often need to reduce a crash testcase for a specific assertion. After writing lots of "only give me this specific assertion" scripts like the above I decided to write a script that automates all this for me: <https://github.com/CTSRD-CHERI/clang/blob/master/utils/creduce_crash_testcase.py>. (It's called creduce_crash_test.py but it will actually use

Looks like I can't access git, documentation, bugs... I'm not sure if this email will actually go through. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171009/e63b709a/attachment.html>

Quentin, thanks so much for looking at this. I should have noticed the other spill to the same stack slot if control doesn't flow through block 2 (line 32). I am sorry to have wasted your time. For the original issue, we won't be able to do anything for the spills, but we can clean up the issue where we materialize the same constant multiple times into the same register just to spill it.

On Thu, Nov 7, 2019 at 9:32 AM Finkel, Hal J. via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On 11/7/19 10:13 AM, Jameson Nash wrote: > > I don't intend to weigh in on either side, but just give a perspective on > a few questions asked. > > From an outsiders perspective, that list isn't what I'd typically describe > as the workflow, since it makes

Thank you both! I was running into the issue that bugpoint was reducing my test-case into other failures and I hadn't managed yet to find the right point in the Julia pass pipeline to insert the module to reproduce the issue reliably from llc and that's why I started looking at using the MIR. I will go back at looking at the pass pipeline and the IR and get a reproducer that way!

I'm not sure exactly what you're after. I was under the impression that you want to know which register is live at a specific point (an instruction). If that's the case, how do one of the two suggested solutions not suffice? If a register is live-in to a block and not killed before your instruction or it has a def and no kill within the block, it is live. Otherwise it is dead and

Thanks for the reduced test case, I’ll try to take a look by the end of the week. > On Feb 20, 2019, at 6:53 PM, Nemanja Ivanovic <nemanja.i.ibm at gmail.com> wrote: > > Finally managed to reduce this to something manageable: https://godbolt.org/z/Hw529k <https://godbolt.org/z/Hw529k> > > On line 40 of the output, we have a load-immediate to put zero into R3. Then we

> On 7 Jul 2017, at 17:12, David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm /guessing/ this is probably pretty normal - but likely the best solution would be to get down to granularity of 1 commit in each of those ranges, to see if it's really justified that the change causes so much recompilation (ie: do all the things that got compiled really depend

Sure. I didn't use lit or ninja. I simply copied the script produced by lit (/home/buildbots/ppc64le-clang-multistage-test/clang-ppc64le-multistage/stage1/tools/clang/test/Driver/Output/target-override.c.script) into a temporary directory (along with a deep copy of the build directory). I modified the paths in the script to point to the temporary directory. Then I ran the script in a loop. For

Should be fixed by https://reviews.llvm.org/D87103 Shall we consider deprecating(emitting a warning)/removing %T from lit? lldb, lld/COFF and clang-tools-extra are the three major users of %T. There are a few other %T in other places but there are not too many. We will also investigate whether other projects using lit are using %T. On Thu, Sep 3, 2020 at 11:25 AM David Blaikie <dblaikie at