search for: propellor

I'm a bit confused by this subthread -- doesn't BOLT have the exact same CFI bloat issue? From my cursory reading of the propellor doc, the CFI duplication is _necessary_ to represent discontiguous functions, not anything particular to the way Propellor happens to generate those discontiguous functions. And emitting discontiguous functions is a fundamental goal of this, right? On Wed, Oct 2, 2019 at 4:25 PM Maksim Panchenko...

Is there large value from deferring the block ordering to link time? That is, does the block layout algorithm need to consider global layout issues when deciding which blocks to put together and which to relegate to the far-away part of the code? Or, could the propellor-optimized compile step instead split each function into only 2 pieces -- one containing an "optimally-ordered" set of hot blocks from the function, and another containing the cold blocks? The linker would have less flexibility in placement, but maybe it doesn't actually need that flex...

...y size bloats. > > > > > > On Wed, Oct 2, 2019 at 1:59 PM James Y Knight via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I'm a bit confused by this subthread -- doesn't BOLT have the exact same CFI bloat issue? From my cursory reading of the propellor doc, the CFI duplication is _necessary_ to represent discontiguous functions, not anything particular to the way Propellor happens to generate those discontiguous functions. > > > > And emitting discontiguous functions is a fundamental goal of this, right? > > > > On Wed, Oc...

...gt; Is there large value from deferring the block ordering to link time? That > is, does the block layout algorithm need to consider global layout issues > when deciding which blocks to put together and which to relegate to the > far-away part of the code? > > > > Or, could the propellor-optimized compile step instead split each function > into only 2 pieces -- one containing an "optimally-ordered" set of hot > blocks from the function, and another containing the cold blocks? The > linker would have less flexibility in placement, but maybe it doesn't > act...

...re large value from deferring the block ordering to link time? That >> is, does the block layout algorithm need to consider global layout issues >> when deciding which blocks to put together and which to relegate to the >> far-away part of the code? >> >> Or, could the propellor-optimized compile step instead split each >> function into only 2 pieces -- one containing an "optimally-ordered" set of >> hot blocks from the function, and another containing the cold blocks? The >> linker would have less flexibility in placement, but maybe it doesn...

On Wed, Oct 2, 2019 at 8:41 PM Maksim Panchenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > *Pessimization/overhead for stack unwinding used by system-wide profilers > and > for exception handling* > > Larger CFI programs put an extra burden on unwinding at runtime as more CFI > (and thus native) instructions have to be executed. This will cause more > overhead

...> > > On Wed, Oct 2, 2019 at 1:59 PM James Y Knight via llvm-dev > > > <llvm-dev at lists.llvm.org> wrote: > > > > > > > > I'm a bit confused by this subthread -- doesn't BOLT have the exact same CFI bloat issue? From my cursory reading of the propellor doc, the CFI duplication is _necessary_ to represent discontiguous functions, not anything particular to the way Propellor happens to generate those discontiguous functions. > > > > > > > > And emitting discontiguous functions is a fundamental goal of this, right? > >...

...gt; Is there large value from deferring the block ordering to link time? That > is, does the block layout algorithm need to consider global layout issues > when deciding which blocks to put together and which to relegate to the > far-away part of the code? > > > > Or, could the propellor-optimized compile step instead split each function > into only 2 pieces -- one containing an "optimally-ordered" set of hot > blocks from the function, and another containing the cold blocks? The > linker would have less flexibility in placement, but maybe it doesn't > act...

...gt; Is there large value from deferring the block ordering to link time? That > is, does the block layout algorithm need to consider global layout issues > when deciding which blocks to put together and which to relegate to the > far-away part of the code? > > > > Or, could the propellor-optimized compile step instead split each function > into only 2 pieces -- one containing an "optimally-ordered" set of hot > blocks from the function, and another containing the cold blocks? The > linker would have less flexibility in placement, but maybe it doesn't > act...

OK, I know this has been asked before, but I'm afraid I can't find it in the archives, so I'm asking *again*. Sorry. I have a USB device (Parallax Propellor USB servo controller http://tinyurl.com/425jm8q) - that uses an FTDI chip to appear on a Windows system as a COM port and which, so far as I can tell, appears on my Linux box as /dev/ttyUSB0 (at least, that device appears when I plug the board in and disappears when I unplug it). How do I get...