llvm-project

Commit Graph

Author	SHA1	Message	Date
Rafael Espindola	a5e536ab0e	Second part of pr16069 The problem this time seems to be a thinko. We were assuming that in the CFG A \| \ \| B \| / C speculating the basic block B would cause only the phi value for the B->C edge to be speculated. That is not true, the phi's are semantically in the edges, so if the A->B->C path is taken, any code needed for A->C is not executed and we have to consider it too when deciding to speculate B. llvm-svn: 183226	2013-06-04 14:11:59 +00:00
David Majnemer	c82f27af2a	SimplifyCFG: Do not transform PHI to select if doing so would be unsafe PR16069 is an interesting case where an incoming value to a PHI is a trap value while also being a 'ConstantExpr'. We do not consider this case when performing the 'HoistThenElseCodeToIf' optimization. Instead, make our modifications more conservative if we detect that we cannot transform the PHI to a select. llvm-svn: 183152	2013-06-03 20:43:12 +00:00

Author

SHA1

Message

Date

Rafael Espindola

a5e536ab0e

Second part of pr16069

The problem this time seems to be a thinko. We were assuming that in the CFG

A
| \
|  B
| /
C

speculating the basic block B would cause only the phi value for the B->C edge
to be speculated. That is not true, the phi's are semantically in the edges, so
if the A->B->C path is taken, any code needed for A->C is not executed and we
have to consider it too when deciding to speculate B.

llvm-svn: 183226

2013-06-04 14:11:59 +00:00

David Majnemer

c82f27af2a

SimplifyCFG: Do not transform PHI to select if doing so would be unsafe

PR16069 is an interesting case where an incoming value to a PHI is a
trap value while also being a 'ConstantExpr'.

We do not consider this case when performing the 'HoistThenElseCodeToIf'
optimization.

Instead, make our modifications more conservative if we detect that we
cannot transform the PHI to a select.

llvm-svn: 183152

2013-06-03 20:43:12 +00:00

2 Commits