[llvm-dev] llvm-dev Digest, Vol 136, Issue 13 - Adding mem2reg pass to pass manager
Alexander Heinisch via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 5 23:43:45 PDT 2015
Send llvm-dev mailing list submissions to
llvm-dev at lists.llvm.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
or, via email, send a message with subject or body 'help' to
llvm-dev-request at lists.llvm.org
You can reach the person managing the list at
llvm-dev-owner at lists.llvm.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of llvm-dev digest..."
Today's Topics:
1. Adding mem2reg pass to pass manager (Riyad Parvez via llvm-dev)
2. Re: Editing metadata (deadal nix via llvm-dev)
3. Re: Adding mem2reg pass to pass manager
(Xiangyang Guo via llvm-dev)
4. Re: Editing metadata (Eric Christopher via llvm-dev)
5. Re: Adding mem2reg pass to pass manager
(Riyad Parvez via llvm-dev)
6. Re: Buildbot Noise (David Blaikie via llvm-dev)
7. Re: Adding mem2reg pass to pass manager (Mehdi Amini via llvm-dev)
8. RFC: Pass for lowering "non-linear" arithmetics of illegal
types (Paweł Bylica via llvm-dev)
9. Re: RFC: Pass for lowering "non-linear" arithmetics of
illegal types (Tim Northover via llvm-dev)
10. Re: RFC: Pass for lowering "non-linear" arithmetics of
illegal types (Matt Arsenault via llvm-dev)
11. Re: Why is printing an Instruction so slow?
(Sean Silva via llvm-dev)
----------------------------------------------------------------------
Message: 1
Date: Mon, 5 Oct 2015 15:48:48 -0400
From: Riyad Parvez via llvm-dev <llvm-dev at lists.llvm.org>
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] Adding mem2reg pass to pass manager
Message-ID:
<CAJhBkVQjOq0_HXWHgXsCYef+fvJnVKcAEPSQaGog+8MVyxFK9A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I want to add "mem2reg" pass similar to this:
PassManager PM;
PM.add(new LoopInfo());
PM.add(new Mem2Reg()); // What's the class name for this pass
> You have to use PM.add(createPromoteMemoryToRegisterPass());
> instead of new Mem2Reg(). It's defined in "llvm/Transforms/Scalar.h"
> and implemented in "llvm/Transforms/Utils/Mem2Reg.cpp".
I couldn't find the name of corresponding class and header file of mem2reg pass except "mem2reg.cpp". So how can I add mem2reg pass into my pass manager?
Thanks,
Riyad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151005/e8fc8db2/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 5 Oct 2015 13:03:57 -0700
From: deadal nix via llvm-dev <llvm-dev at lists.llvm.org>
To: Eric Christopher <echristo at gmail.com>
Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Editing metadata
Message-ID:
<CANGV3T2waeEei5pFzmpYDZO5D=P0e8wdewMXwsfAh4SqX1fLmA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ok, so my best shot at this would be to just throw away existing debug infos and regenerating new ones, if I understand you.
That would work, I was hoping for something better, but it will do. Thank you.
2015-10-05 10:20 GMT-07:00 Eric Christopher <echristo at gmail.com>:
> This is about the best idea. There's no way to take the non-temporary
> md nodes back to temporary.
>
> -eric
>
> On Mon, Oct 5, 2015 at 10:12 AM Robinson, Paul via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Abstractly, (I don't get inside this code as much as I should) debug
>> info works on a translation-unit basis, not a function basis, so
>> regenerating a single function's debug info is not a natural or well-isolated operation.
>>
>> You might have to emit each function as its own LLVM module and
>> re-JIT the module?
>>
>> People more deeply familiar with how the metadata stuff works might
>> be able to offer better suggestions.
>>
>> --paulr
>>
>>
>>
>> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf
>> Of *deadal nix via llvm-dev
>> *Sent:* Friday, October 02, 2015 11:38 PM
>> *To:* llvm-dev
>> *Subject:* [llvm-dev] Editing metadata
>>
>>
>>
>> Hi all,
>>
>> I'm using the JIT capabilities of LLVM. But so far, I've been unable
>> to use the debug capabilities of LLVM in conjunction with the JIT.
>> The problematic scenario goes as follow :
>>
>> - Emit some IR with debug infos.
>>
>> - Install hooks to get back into some codepath that I do not wish to
>> codegen at this stage.
>>
>> - JIT the method. This require to finalize the DIBuilder to complete
>> the emission of debug metadata.
>>
>> - Later on, emit IR for some of the missing branches. Here the
>> problem surface :
>>
>> - Without debug infos, the codegen for this specific method can
>> be invalidated and redone, all is fine.
>>
>> - With debug infos, the metadata have been finalized already, and
>> it doesn't seems that it is possible to revert this
>>
>> Is there a way to make that work ? If not, is there a patch I can
>> work on to make that work ?
>>
>> Thank in advance,
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151005/5fdd413b/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 5 Oct 2015 16:04:59 -0400
From: Xiangyang Guo via llvm-dev <llvm-dev at lists.llvm.org>
To: Riyad Parvez <riyad.parvez at uwaterloo.ca>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Adding mem2reg pass to pass manager
Message-ID:
<CAApsxOEE1jCT-FwVk=5EpOAjrrtzmu7W1dcY9fAZKxc=SMAmrQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
PM.add(createPromoteMemoryToRegisterPass()) works for me. Hope this helpful.
Thanks,
Xiangyang
2015-10-05 15:48 GMT-04:00 Riyad Parvez via llvm-dev <
llvm-dev at lists.llvm.org>:
> Hi,
>
> I want to add "mem2reg" pass similar to this:
>
> PassManager PM;
> PM.add(new LoopInfo());
> PM.add(new Mem2Reg()); // What's the class name for this pass
>
>
> I couldn't find the name of corresponding class and header file of
> mem2reg pass except "mem2reg.cpp". So how can I add mem2reg pass into
> my pass manager?
>
> Thanks,
> Riyad
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151005/af4edf17/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 05 Oct 2015 20:06:01 +0000
From: Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org>
To: deadal nix <deadalnix at gmail.com>
Cc: "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Editing metadata
Message-ID:
<CALehDX5HHbfF602HpUuaNMwkgRjJ5xAtasX8x+YJnv_3jCYZmw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yep. That's your best bet. I think if you're effectively regenerating the IR from scratch (it's what it feels like to me) then you should probably regenerate the debug information. If you were just deciding to optimize it after a run or two then that should be fine and be able to get updated.
-eric
On Mon, Oct 5, 2015 at 1:04 PM deadal nix <deadalnix at gmail.com> wrote:
> Ok, so my best shot at this would be to just throw away existing debug
> infos and regenerating new ones, if I understand you.
>
> That would work, I was hoping for something better, but it will do.
> Thank you.
>
> 2015-10-05 10:20 GMT-07:00 Eric Christopher <echristo at gmail.com>:
>
>> This is about the best idea. There's no way to take the non-temporary
>> md nodes back to temporary.
>>
>> -eric
>>
>> On Mon, Oct 5, 2015 at 10:12 AM Robinson, Paul via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Abstractly, (I don't get inside this code as much as I should) debug
>>> info works on a translation-unit basis, not a function basis, so
>>> regenerating a single function's debug info is not a natural or
>>> well-isolated operation.
>>>
>>> You might have to emit each function as its own LLVM module and
>>> re-JIT the module?
>>>
>>> People more deeply familiar with how the metadata stuff works might
>>> be able to offer better suggestions.
>>>
>>> --paulr
>>>
>>>
>>>
>>> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf
>>> Of *deadal nix via llvm-dev
>>> *Sent:* Friday, October 02, 2015 11:38 PM
>>> *To:* llvm-dev
>>> *Subject:* [llvm-dev] Editing metadata
>>>
>>>
>>>
>>> Hi all,
>>>
>>> I'm using the JIT capabilities of LLVM. But so far, I've been unable
>>> to use the debug capabilities of LLVM in conjunction with the JIT.
>>> The problematic scenario goes as follow :
>>>
>>> - Emit some IR with debug infos.
>>>
>>> - Install hooks to get back into some codepath that I do not wish
>>> to codegen at this stage.
>>>
>>> - JIT the method. This require to finalize the DIBuilder to
>>> complete the emission of debug metadata.
>>>
>>> - Later on, emit IR for some of the missing branches. Here the
>>> problem surface :
>>>
>>> - Without debug infos, the codegen for this specific method can
>>> be invalidated and redone, all is fine.
>>>
>>> - With debug infos, the metadata have been finalized already,
>>> and it doesn't seems that it is possible to revert this
>>>
>>> Is there a way to make that work ? If not, is there a patch I can
>>> work on to make that work ?
>>>
>>> Thank in advance,
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151005/74e23ead/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 5 Oct 2015 16:09:31 -0400
From: Riyad Parvez via llvm-dev <llvm-dev at lists.llvm.org>
To: Xiangyang Guo <eceguo at gmail.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Adding mem2reg pass to pass manager
Message-ID:
<CAJhBkVTiLmawEPOLgc2GaM_0npYsvk5NFw74so0eGKRtqPiaZQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Oct 5, 2015 at 4:04 PM, Xiangyang Guo <eceguo at gmail.com> wrote:
> PM.add(createPromoteMemoryToRegisterPass())
>
Did you include "Mem2Reg.cpp"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151005/5d06d2c7/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 5 Oct 2015 14:28:23 -0700
From: David Blaikie via llvm-dev <llvm-dev at lists.llvm.org>
To: Renato Golin <renato.golin at linaro.org>
Cc: LLVM Dev <llvm-dev at lists.llvm.org>, Clang Dev
<cfe-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Buildbot Noise
Message-ID:
<CAENS6EvUD_PrUmTXtB8q+kOvSgThO2-WrMp3L4Bdz=_StOuWhQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Thu, Oct 1, 2015 at 10:31 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> Folks,
>
> David has been particularly militant with broken buildbots recently,
> so to make sure we don't throw the baby with the bath water, I'd like
> to propose some changes on how we deal with the emails on our
> *current* buildmaster, since there's no concrete plans to move it to
> anything else at the moment.
>
> The main issue is that managing the buildbots is not a simple task. It
> requires build owners to disable on the slave side, or specific people
> on the master side. The former can take as long as the owner wants
> (which is not nice), and the latter refreshes all active bots
> (triggering exceptions) and are harder to revert.
>
> We need to be pragmatic without re-writing the BuildBot product.
>
> Grab some popcorn...
>
> There are two main fronts that we need to discuss the noise: Bot and
> test stability.
>
>
> 1. Bot stability issues
>
> We need to distinguish between four classes of buildbots:
>
> 1.1. Fast && stable && green
>
> These buildbots normally finish under one hour, but most of the time
> under 1/2 hour and should be kept green as much as possible.
> Therefore, any reasonable noise
Not sure what kind of noise you're referring to here. Flaky fast builders would be a bad thing, still - so that sort of noise should still be questioned.
> in these bots are welcomed, since we
> want them to go back to green as soon as possible.
>
> They're normally the front-line, and usually catch most of the silly
> bugs. But we need some kind of policy that allows us to revert patches
> that break them for more than a few hours.
I'm not sure if we need extra policy here - but I don't mind documenting the common community behavior here to make it more clear.
Essentially: if you've provided a contributor with a way to reproduce the issue, and it seems to clearly be a valid issue, revert to green & let them look at the reproduction when they have time. We do this pretty regularly (especially outside office hours when we don't expect someone will be around to revert it themselves - but honestly, I don't see that as a requirement - if you've provided the evidence for them to investigate, revert first & they can investigate whenever they get to it, sooner or
later)
> We have an agreement
> already, and for me that's good enough. People might think
> differently.
>
> With the items 2.x below taken care of, we should keep the current
> state of our bots for this group.
>
> 1.2. One of: Slow || Unstable || Often Red
>
> These bots are special. They're normally *very* important, but have
> some issues, like slow hardware, not too many available boards, or
> they take long times to bisect and fix the bugs.
>
Long bisection is a function of not enough boards (producing large revision ranges for each run), generally - no? (or is there some other reason?)
> These bots catch the *serious* bugs,
Generally all bots catch serious bugs - it's just a long tail: fast easy to find bugs, then longer tests find the harder to find bugs, and so on and so forth. (until we get below the value/bug thershold where it's not worth expending the CPU cycles to find the next bug)
> like self-hosted Clang
> mis-compiling a long-running test which sometimes fails. They can
> produce noise, but when the noise is correct, we really need to listen
> to it. Writing software to understand that is non-trivial.
>
Again, not sure which kind of noise you're referring to here - it'd be helpful to clarify/disambiguate. Flaky or often-red results on slow buildbots without enough resources (long blame lists) are pretty easily ignored ("oh, it could be any of those 20 other people's patches, I'll just ignore it - someone else will do the work & tell me if it's my fault").
> So, the idea here is to have a few special treatments for each type of
> problem.
But they are problems that need to be addressed, is the key - and arguably, until they are addressed, these bots should only report to the owner, not to contributors. (as above - if people generally ignore them because they're not accurate enough to believe that it's 'your' fault, then they essentially are already leaving it to the owner to do the investigation - they just have extra email they have to ignore too, let's remove the email so that we can make those we send more valuable by not getting lost in the
noise)
> For example, slow bots need more hardware to reduce the blame list.
Definitely ^.
> Unstable bot need more work to reduce spurious noise to a minimum (see
> 2.x below), and red bots *must* remain *silent* until they come back
> to green (see 2.x below).
>
As I mentioned on IRC/other threads - having red bots, even if they don't send email, does come at some cost. It makes dashboards hard to read. So for those trying to get a sense of the overall state of the project (what's on fire/what needs to be investigated) this can be problematic. Having issues XFAILed (with a bug filed, or someone otherwise owning the issue until the XFAIL is removed) or reverted aggressively or having bots moved into a separate group so that there's a clear "this is the stuff we should expect to be green all the time" group that can be eyeballed quickly, is nice.
> What we *don't* want is to disable or silence them after they're
> green. Most of the bugs they find are hard to debug, so the longer we
> take to fix it the harder it is to find out what happened. We need to
> know as soon as possible when they break.
>
I still question whether these bots provide value to the community as a whole when they send email. If the investigation usually falls to the owners rather than the contributors, then the emails they send (& their presence on a broader dashboard) may not be beneficial.
So to be actionable they need to have small blame lists and be reliable (low false positive rate). If either of those is compromised, investigation will fall to the owner and ideally they should not be present in email/core dashboard groups.
>
> 1.3. Two of: Slow || Unstable || Often Red
>
> These bots are normally only important to their owners, and they are
> on the verge of being disabled.
I don't think they have to be on the verge of being disabled - so long as they don't send email and are in a separate group, I don't see any problem with them being on the main llvm buildbot. (no particular benefit either, I suppose - other than saving the owner the hassle of running their own master, which is fine)
> The only way to cope with those bots
> is to completely disable their emails / IRC messages, so that no one
> gets flooded with noise from broken bots.
>
Yep
> However, some bots on the 1.2 category fall into this one for short
> periods of time (~1 week), so we need to be careful with what we
> disable here. That's the key baby/bathwater issue.
>
> Any hard policy here will be wrong for some bots some of the time, so
> I'd love if we could all just trust the bot owners a bit when they say
> they're fixing the issue.
It's not a question of trust, from my perspective - regardless of whether they will address the issue or not, the emails add noise and decrease the overall trust developers have in the signal (via email, dashboards and IRC) from the buildbots.
If an issue is being investigated we have tools to deal with that: XFAIL, revert, and buildbot reconfig (we could/should check if the reconfig for email configuration can be done without a restart - yes, it still relies on a buildbot admin to be available (perhaps we should have more people empowered to reconfig the buildmaster to make this cheaper/easier) but without the interruption to all builds).
If there's enough hardware that blame lists are small and the bot is reliable, then reverts can happen aggressively. If not, XFAIL is always an option too.
> However, bots that fall here for more than a month, or more often that
> a few times during a few months (I'm being vague on purpose), then we
> collectively decide to disable the bot.
>
> What I *don't* want is any two or three guys deciding to disable the
> buildbot of someone else because they can't stand the noise. Remember,
> people do take holidays once in a while, and they may be in the Amazon
> or the Sahara having well deserved rest. Returning to work and
> learning that all your bots are disabled for a week is not nice.
>
I disagree here - if the bots remain red, they should be addressed. This is akin to committing a problematic patch before you leave - you should expect/hope it is reverted quickly so that you're not interrupting everyone's work for a week.
If your bot is not flakey and has short blame lists, I think it's possibly reasonable to expect that people should revert their patches rather than disable the bot or XFAIL the test on that platform. But without access to hardware it may be hard for them to investigate the failure - XFAIL is probably the right tool, then when the owner is back they can provide a reproduction, extra logs, help remote-debug it, etc.
> So far, we have coped with noise, and the result is that people tend
> to ignore those bots, which means more work to the bot owner.
The problem is, that work doesn't only fall on the owners of the bots which produce the noise. It falls on all bot owners because developers become immune/numb to bot failure mail to a large degree.
> This is
> not a good situation, and we want to move away from it, but we
> shouldn't flip all switches off by default. We can still be pragmatic
> about this as long as we improve the quality overall (see 2.x below)
> with time.
>
> In summary, bots that fall here for too long will have their emails
> disabled and candidates for removal in the next spring clean-up, but
> not immediately.
>
> 1.4. Slow && Unstable && Red
>
> These bots don't belong here. They should be moved elsewhere,
> preferably to a local buildmaster that you can control and that will
> never email people or upset our master if you need changes. I have
> such a local master myself and it's very easy to setup and maintain.
>
Yep - bots that are only useful to the owner (some of the situations above I think constitute this situation, but anyway) shouldn't email/show up in the main buildbot group. But I wouldn't mind if we had a separate grouping in the dashboards for these bots (I think we have an experimental group which is somewhat like this). No big deal either way to me. If they're not sending mail/IRC messages, and they're not in the main group on the dashboard, I'm OK with it.
> They *do* have value to *you*, for example to show the progress of
> your features cleaning up the failures, or generating some benchmark
> numbers, but that's something that is very specific to your project
> and should remain separated.
>
> Any of these bots in LLVM Lab should be moved away / removed, but on
> consensus, including the bot owner if he/she is still available in the
> list.
>
>
> 2. Test stability issues
>
> These issues, as you may have noticed from the links above, apply to
> *all* bots. The less noise we have overall, the lower will be our
> threshold for kicking bots out of the critical pool, and the higher
> the value of the not-so-perfect buildbots to the rest of the
> community.
>
I'm not quite sure I follow this comment. The less noise we have, the /more/ problematic any remaining noise will be (because it'll be costing us more relative to no-noise - when we have lots of noise, any one specific source of noise isn't critical, we can remove it but it won't change much - when there's a little noise, removing any one source substantially decreases our false positive rate, etc)
>
> 2.1 Failed vs Exception
>
> The most critical issue we have to fix is the "red -> exception ->
> red" issue. Basically, a bot is red (because you're still
> investigating the problem), then someone restarts the master, so you
> get an exception. The next build will be a failure, and the
> buildmaster recognises the status change and emails everyone. That's
> just wrong.
>
> We need to add an extra check to that logic where it searches down for
> the next non-exceptional status and compares to that, not just the
> immediately previous result.
>
> This is a no-brainer and I don't think anyone would be against it. I
> just don't know where this is done, I welcome the knowledge of more
> experienced folks.
>
Yep, sounds like we might be able to have Galina look into that. I have no context there about where that particular behavior might be (whether it's in the buildbot code itself, or in the user-provided buildbot configuration, etc).
>
> 2.2 Failure types
>
> The next obvious thing is to detect what the error is. If it's an SVN
> error, we *really* don't need to get an email.
Depends on the error - if it's transient, then this is flakiness as always & should be addressed as such (by trying to remove/address the flakes).
Though, yes, this sort of failure should, ideally, probably, go to the buildbot owner but not to users.
> But this raises the
> problem that an SVN failure followed by a genuine failure will not be
> reported. So, the reporting mechanism also has to know what's the
> previously *reported* failure, not just the previous failure.
>
> Other failures, like timeout, can be either flaky hardware or broken
> codegen. A way to be conservative and low noise would be to only warn
> on timeouts IFF it's the *second* in a row.
>
I don't think this helps - this reduces the incidence, but isn't a real solution. We should reduce the flakiness of hardware. If hardware is this unreliable, why would we be building a compiler for it? No user could rely on it to produce the right answer. (& again, if the flakiness is bad enough
- I think that goes back to an owner-triaged bot, one that doesn't send mail, etc)
> For all these adjustments, we'll need some form of walk-back on the
> history to find the previous genuine result, and we'll need to mark
> results with some metadata. This may involve some patches to buildbot.
>
Yeah, having temporally related buildbot results seems dubious/something I'd be really cautious about.
> 2.3 Detecting fixed bots
>
> Another interesting feature, that is present in the "GreenBot" is a
> warning when a bot you broke was fixed. That, per se, is not a good
> idea if the noise levels are high, since this will probably double it.
>
> So, this feature can only be introduced *after* we've done the clean
> ups above. But once it's clean, having a "green" email will put the
> minds of everyone that haven't seen the "red" email yet to rest, as
> they now know they don't even need to look at it at all, just delete
> the email.
>
> For those using fetchmail, I'm sure you could create a rule to do that
> automatically, but that's optional. :)
>
Yeah, I don't know what the right solution is here at all - but it certainly would be handy if there were an easier way to tell if an issue has been resolved since your commit.
I imagine one of the better options would be some live embedded HTML that would just show a green square/some indicator that the bot has been green at least once since this commit.
(that doesn't help if you introduced a flaky test, though... - that's harder to deal with/convey to users, repeated test execution may be necessary in that case - that's when temporal information may be useful)
>
> 2.4 Detecting new failures
>
> This is a wish-list that I have, for the case where the bots are slow
> and hard to debug and are still red. Assuming everything above is
> fixed, they will emit no noise until they go green again, however,
> while I'm debugging the first problem, others can appear. If that
> happens, *I* want to know, but not necessarily everyone else.
>
This seems like the place where XFAIL would help you and everyone else. If the original test failure was XFAILed immediately, the bot would go green, then red again if a new failure was introduced. Not only would you know, but so would the auhtor of the change.
>
> So, a list of problems reported could be added to the failure report,
> and if the failure is different, the bot owner gets an email. This
> would have to play nice with exception statuses, as well as spurious
> failures like SVN or timeouts, so it's not an easy patch.
>
> The community at large would be already happy with all the changes
> minus this one, but folks that have to maintain slow hardware like me
> would appreciate this feature. :)
>
>
>
> Does any one have more concerns?
>
> AFAICS, we should figure out where the walk-back code needs to be
> inserted and that would get us 90% of the way. The other 10% will be
> to list all the buildbots, check their statuses, owners, and map into
> those categories, and take the appropriate action.
>
> Maybe we should also reduce the noise in the IRC channel further (like
> only first red, first green), but that's not my primary concern right
> now. Feel free to look into it if it is for you.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151005/4ef8bbf2/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 05 Oct 2015 14:45:30 -0700
From: Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org>
To: Riyad Parvez <riyad.parvez at uwaterloo.ca>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Adding mem2reg pass to pass manager
Message-ID: <C6541B94-D235-44C0-B97A-1E0DFCE70317 at apple.com>
Content-Type: text/plain; charset="utf-8"
> On Oct 5, 2015, at 1:09 PM, Riyad Parvez via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>
> On Mon, Oct 5, 2015 at 4:04 PM, Xiangyang Guo <eceguo at gmail.com <mailto:eceguo at gmail.com>> wrote:
> PM.add(createPromoteMemoryToRegisterPass())
>
> Did you include "Mem2Reg.cpp”?
$ grep createPromoteMemoryToRegisterPass include -R
include/llvm/LinkAllPasses.h: (void) llvm::createPromoteMemoryToRegisterPass();
include/llvm/Transforms/Scalar.h:FunctionPass *createPromoteMemoryToRegisterPass();
It seem this should be enough: #include “llvm/Transforms/Scalar.h”
—
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151005/cabd4d5f/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 05 Oct 2015 22:09:48 +0000
From: Paweł Bylica via llvm-dev <llvm-dev at lists.llvm.org>
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] RFC: Pass for lowering "non-linear" arithmetics of
illegal types
Message-ID:
<CAE7VtSdjGQHfYY7ApnfWVd20RuoFpvbXp9L2xA0Ws8XqrvdxvA at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi LLVM,
This is my idea I had some time ago, when I realized that LLVM did not support legalization of some arithmetic instructions like mul i256. I have implemented very simple and limited version of that in my project. Is it something LLVM users would appreciate?
1. The pass transforms IR and is meant to be run before CodeGen (after
IR optimizations).
2. The pass replaces instructions mul, udiv, urem, sdiv, srem that are
know to be not supported by target's type legalization with a call to a
function that implements given arithmetic operation.
3. The pass also injects these functions to the module with a weak
linkage.
4. The pass requires a function generator (interface implementation) for
mul and udivrem algorithms for integer types of sizes being powers of 2
(i.e. i128, i256, ...). Replacements for other instructions are created
using these 2 algorithms.
5. A default implementation of the generator is provided.
6. A user is able to provide its own implementation of the generator
with algorithms better suitable for user's cases and/or for other than
default instructions (e.g. sdiv i256, urem i199).
- Paweł
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151005/886c325e/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 5 Oct 2015 15:25:06 -0700
From: Tim Northover via llvm-dev <llvm-dev at lists.llvm.org>
To: Paweł Bylica <chfast at gmail.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: Pass for lowering "non-linear"
arithmetics of illegal types
Message-ID:
<CAFHTzfKf6wwLzAUZS2Win+Y+AG-HqvyunhXmYpqLVRX8SO05bw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 5 October 2015 at 15:09, Paweł Bylica <llvm-dev at lists.llvm.org> wrote:
> The pass replaces instructions mul, udiv, urem, sdiv, srem that are
> know to be not supported by target's type legalization with a call to
> a function that implements given arithmetic operation.
This seems quite sensible, those functions can get bigger than you'd want to inline.
> The pass also injects these functions to the module with a weak linkage.
> The pass requires a function generator (interface implementation) for
> mul and udivrem algorithms for integer types of sizes being powers of 2 (i.e.
> i128, i256, ...). Replacements for other instructions are created
> using these 2 algorithms.
This sounds a bit weird though. It seems more natural to make these part of a runtime support library for your language (like compiler-rt is for C).
Cheers.
Tim.
------------------------------
Message: 10
Date: Mon, 5 Oct 2015 15:26:48 -0700
From: Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org>
To: Tim Northover <t.p.northover at gmail.com>, Paweł Bylica
<chfast at gmail.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] RFC: Pass for lowering "non-linear"
arithmetics of illegal types
Message-ID: <5612F928.8070904 at amd.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
On 10/05/2015 03:25 PM, Tim Northover via llvm-dev wrote:
> This sounds a bit weird though. It seems more natural to make these
> part of a runtime support library for your language (like compiler-rt
> is for C).
This makes sense for GPUs without call support / machine linking support. I would like to be able to replace all expand runtime library calls with calls to IR functions we can inline.
------------------------------
Message: 11
Date: Mon, 5 Oct 2015 15:31:48 -0700
From: Sean Silva via llvm-dev <llvm-dev at lists.llvm.org>
To: Reid Kleckner <rnk at google.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Why is printing an Instruction so slow?
Message-ID:
<CAHnXoanVGxYE6K7JMroP1rtOQPKuMfj3XQT+4j_LBQR7_ApL3g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Mon, Oct 5, 2015 at 9:36 AM, Reid Kleckner via llvm-dev < llvm-dev at lists.llvm.org> wrote:
> Instruction printing is usually slow because it uses SlotNumbering,
> which is a whole function analysis to determine what numbers to use
> for unnamed values.
>
> If printing is part of your critical path, you can use
> 'Value::print(raw_ostream&, ModuleSlotTracker&)' instead of
> operator<<. I believe it will help you do the analysis once and print many instructions.
>
It is still linear in the number of types in the module. (I recently tried to reduce llvm-diff's O((module size)^2) complexity by using ModuleSlotTracker but it still was quadratic even when using
moduleslottracker)
-- Sean Silva
>
> On Mon, Oct 5, 2015 at 8:17 AM, Stephen Thomas via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi all,
>>
>> When writing my custom passes, I often emit log messages to
>> llvm::errs() like so:
>>
>> llvm::errs() << "Could not handle instruction: " << *Inst <<
>> std::endl;
>>
>> where Inst is a pointer to an Instruction.
>>
>> I've profiled my code and found that this way of printing an
>> Instruction takes a very long time: indeed, it is the bottleneck of my pass.
>>
>> Of course, I could always switch these log messages off for
>> production runs, but during development and debugging, I'd like to
>> have them on to make debugging much easier.
>>
>> Is there a faster way to print an Instruction?
>>
>> Thanks,
>> Steve
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151005/e235038b/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
llvm-dev mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
------------------------------
End of llvm-dev Digest, Vol 136, Issue 13
*****************************************
More information about the llvm-dev
mailing list