similar to: Broadvoice - Last Straw!

There seems to be a lot of interest recently in LTO. How do you see the situation of splitting the IR passes between per-TU processing and multi-TU ("link time") processing? -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130717/f5310a6e/attachment.html>

On Mon, Jul 29, 2013 at 4:24 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > Out of curiosity, has anyone tried to optimize the pass ordering in some > (quasi-)automated way? Naively, a genetic algorithm seems like a perfect > fit for this. > This is the closest I've seen: http://donsbot.wordpress.com/2010/03/01/evolving-faster-haskell-programs-now-with-llvm/ However, it

I personally strong abhor this kind of thing:-) I guess I should be more open-minded. For pre-ipo phase, some passes should not invoke, say, any loop nest-opt, loop version, aggressive loop unrolling, vectorization, aggressive inling. The reasons are they will hinder the downstream optimizers if they kick in early. > Out of curiosity, has anyone tried to optimize the pass ordering in some

On Jul 31, 2013, at 6:53 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/30/2013 11:44 PM, Chris Lattner wrote: >> >> The canonical form should be that loop invariants are hoisted. > > The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common"

>> I'm talking about perfect loop nests, as in the classical fortran loop >> transformation sense. > > Most nest optimizations only apply to perfect nests. Each such > optimization could try to "fix" the nest for its own purposes, but it > would be a lot of duplicated effort. If each L.N.O pass have to fix by itself, I would say this LNO component is

On 7/31/2013 6:30 PM, Tobias Grosser wrote: > > I can see us following Andrews > suggestion to disable LICM in case a LNO is run and having the LNO > schedule an additional set of cleanup passes later on. The way I was thinking about it is that LICM could be optionally added to the preparation steps, something like requiring loop-closed SSA form for certain transformations. -K --

On 7/30/2013 11:44 PM, Chris Lattner wrote: > > The canonical form should be that loop invariants are hoisted. The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common" properties of a loop, such as header, preheader, latch branch, etc. > Optimizations should not depend on perfect

On 7/31/2013 12:20 PM, Chris Lattner wrote: > On Jul 31, 2013, at 6:53 AM, Krzysztof Parzyszek > <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote: >> On 7/30/2013 11:44 PM, Chris Lattner wrote: >>> >>> The canonical form should be that loop invariants are hoisted. >> >> The canonical form should not depend on the knowledge

On 7/31/13 4:47 PM, Shuxin Yang wrote: > > On 7/31/13 4:30 PM, Tobias Grosser wrote: >> On 07/30/2013 09:44 PM, Chris Lattner wrote: >>> >>> On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> >>> wrote: >>> >>>> The pro for running LICM early is that it may move big redundant >>>> stuff out of loop

On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > The pro for running LICM early is that it may move big redundant stuff out of loop nest. You never know > how big it is. In case you are lucky , you can move lot of stuff out of > loop, the loop may become much smaller and hence enable lots of downstream optimizations. This sound > to be a big win

----- Original Message ----- > > On Jul 27, 2013, at 5:47 PM, Shuxin Yang <shuxin.llvm at gmail.com> > wrote: > > > Hi, Sean: > > > > I'm sorry I lie. I didn't mean to lie. I did try to avoid making > > a *BIG* change > > to the IPO pass-ordering for now. However, when I make a minor > > change to > >

On 7/31/13 4:30 PM, Tobias Grosser wrote: > On 07/30/2013 09:44 PM, Chris Lattner wrote: >> >> On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: >> >>> The pro for running LICM early is that it may move big redundant >>> stuff out of loop nest. You never know >>> how big it is. In case you are lucky , you can move

On 7/16/2013 11:38 PM, Andrew Trick wrote: > Since introducing the new TargetTransformInfo analysis, there has been some confusion over the role of target heuristics in IR passes. A few patches have led to interesting discussions. > > To centralize the discussion, until we get some documentation and better APIs in place, let me throw out an oversimplified Straw Man for a new pass pipline.

On 7/30/13 7:35 AM, Krzysztof Parzyszek wrote: > On 7/29/2013 6:28 PM, Andrew Trick wrote: >> >> You mean that LICM and Unswitching should be left for later? For the >> purpose of exposing scalar optimizations, I'm not sure I agree with >> that but I'd be interested in examples. > > Optimizations like LICM, and unswitching can potentially damage >

Hi, i'm having problems with broadvoice incoming calls. I can perfectly place calls but my Asterisk Box is having problems when registering with the SIP Proxy. Sometimes it register and the call gets into asterisk, but without sound (seems to be NAT problems) and sometimes its not possible for asterisk to receive the calls. Everything was working great exactly for a month, but a week ago it

Hi all, I am trying to configure my Asterisk PBX to connect to a broadvoice account. I want incoming calls to go to the "s" extension and to ultimately have outbound calls routed through my broadvoice account(s). I cannot for the life of me get this to register correctly. I am currently receiving this message on the console: Failed to authenticate on Register to

Is anyone else experiencing 404 errors on outbound dial with Broadvoice? I've followed the instructions posted by Broadvoice to configure sip.conf, and inbound calling works fine. Every time I try to dial out, I get a 404 "Not Found" error. Here are the relevant sections from my configs. sip.conf: context=broadvoice-in register =>

I have searched the list and cannot find a sip 400 solution posted that solves my problem. If anyone has any thoughts or suggestions on the following I would greatly appreciate it. I didn't have this error before Broadvoice made their changes this weekend. Now when I make a call it connects but, I cannot hear anything on the other end... The full message I have is: 8 headers, 0 lines

So it was all working well and then suddenly I'm unable to get incoming calls from BV. Outgoing is fine. I'm using AAH. I have the following settings; register=9738281625@sip.broadvoice.com:PASSWORD-GOES-HERE:9738281625@sip.broadvoice.com/2208 [broadvoice] username=9738281625 user=phone type=peer secret=PASSWORD-GOES-HERE qualify=1000 port=5060 nat=yes insecure=very

> > I've tried setting up my sip.conf in two ways: > > > ------------------------------------------------------ > register => [240xxxxxxx]:[my_password]@sip.broadvoice.com > > > [Broadvoice] > type=peer > username=[240xxxxxxx] > fromuser=[240xxxxxxx] > secret=[my_password] > host=sip.broadvoice.com > context=incoming >