You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some values of loop perforation knobs cause the version of llc shipped with LLVM 3.2 to crash during isel ( 👍 ) on the MSP430 benchmarks. accept.core.build() quite sensibly raises a BuildError, but this causes accept run to bail. I'd argue that that result should be simply triaged as bad instead; the parameter-space exploration could continue.
It's not just this test case. I can imagine BuildErrors resulting from knob adjustments in other scenarios too, for example when relaxing something causes an aggressive analysis to decide there's an error.
The text was updated successfully, but these errors were encountered:
Awesome, very awesome, thanks LLVM isel. Yes, let's suppress these for the sake of fault isolation.
I'm not sure whether it should be allowed for optimizations to fail when they're applied. It seems like they should do all their work up front (at analysis time) to determine whether it's safe to apply. This avoids bothering the autotuner with stuff that won't work out anyway. But it could be infeasible to do that for some optimizations... worth continuing to think about.
Some values of loop perforation knobs cause the version of
llc
shipped with LLVM 3.2 to crash during isel ( 👍 ) on the MSP430 benchmarks.accept.core.build()
quite sensibly raises aBuildError
, but this causesaccept run
to bail. I'd argue that that result should be simply triaged as bad instead; the parameter-space exploration could continue.It's not just this test case. I can imagine
BuildError
s resulting from knob adjustments in other scenarios too, for example when relaxing something causes an aggressive analysis to decide there's an error.The text was updated successfully, but these errors were encountered: