{"push_id":2918595221,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"e16c856a2dff4ba520915d468ba7ddd61fe15fb3","before":"67a2fd5526e839b784ebd698ce75d677101d7449","commits":[{"sha":"e16c856a2dff4ba520915d468ba7ddd61fe15fb3","author":{"name":"Craig Topper","email":"0c9ca018c303606191d06dd2c0bdf1206717c3f3@intel.com"},"message":"[X86] Disable BMI BEXTR in X86DAGToDAGISel::matchBEXTRFromAnd unless we're on compiling for a CPU with single uop BEXTR\n\nSummary:\nThis function turns (X >> C1) & C2 into a BMI BEXTR or TBM BEXTRI instruction. For BMI BEXTR we have to materialize an immediate into a register to feed to the BEXTR instruction.\n\nThe BMI BEXTR instruction is 2 uops on Intel CPUs. It looks like on SKL its one port 0/6 uop and one port 1/5 uop. Despite what Agner's tables say. I know one of the uops is a regular shift uop so it would have to go through the port 0/6 shifter unit. So that's the same or worse execution wise than the shift+and which is one 0/6 uop and one 0/1/5/6 uop. The move immediate into register is an additional 0/1/5/6 uop.\n\nFor now I've limited this transform to AMD CPUs which have a single uop BEXTR. If may also might make sense if we can fold a load or if the and immediate is larger than 32-bits and can't be encoded as a sign extended 32-bit value or if LICM or CSE can hoist the move immediate and share it. But we'd need to look more carefully at that. In the regression I looked at it doesn't look load folding or large immediates were occurring so the regression isn't caused by the loss of those. So we could try to be smarter here if we find a compelling case.\n\nReviewers: RKSimon, spatel, lebedev.ri, andreadb\n\nReviewed By: RKSimon\n\nSubscribers: llvm-commits, andreadb, RKSimon\n\nDifferential Revision: https://reviews.llvm.org/D52570","distinct":true,"url":"https://api.github.com/repos/llvm-project/llvm-project-20170507/commits/e16c856a2dff4ba520915d468ba7ddd61fe15fb3"}]}
{"actor":{"display_login":"chapuni"}}