search for: 109154

...-dev/2017-January/109185.html> for the details.) > > > * How likely GlobalISel will break on non-related change? > > Unlikely: GlobalISel's APIs are fairly isolated or work on pretty well established low-level APIs. (See http://lists.llvm.org/pipermail/llvm-dev/2017-January/109154.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/109154.html> for details.) > > > * Why GlobalISel wasn’t built from the start? > > One of the requirement was that we don’t impact negatively the footprint of the compiler. Given we were not sure where we were going...

...9185.html> for the details.) >> >> >> * How likely GlobalISel will break on non-related change? >> >> Unlikely: GlobalISel's APIs are fairly isolated or work on pretty well established low-level APIs. (See http://lists.llvm.org/pipermail/llvm-dev/2017-January/109154.html <http://lists.llvm.org/pipermail/llvm-dev/2017-January/109154.html> for details.) >> >> >> * Why GlobalISel wasn’t built from the start? >> >> One of the requirement was that we don’t impact negatively the footprint of the compiler. Given we were not sure...

On Wed, Jan 18, 2017 at 9:13 AM David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > These concerns sound applicable to the situation when GlobalISel is turned > on by default and has an effect on code generation. > > While it's a library with tests like any other LLVM component I don't see > these concerns as being significantly greater risk than any