[PATCH] D22042: [AArch64] Macro fusion of simple ALU ops with branches for Broadcom's Vulcan

pankaj gode via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 8 00:27:19 PDT 2016

pgode added inline comments.

Comment at: lib/Target/AArch64/AArch64InstrInfo.cpp:1806
@@ -1805,1 +1805,3 @@
     if (SecondOpcode == AArch64::Bcc) {
+      if (Subtarget.getProcFamily() == AArch64Subtarget::Vulcan) {
+        // All simple ALU operations that use one micro-op
rengolin wrote:
> pgode wrote:
> > rengolin wrote:
> > > rengolin wrote:
> > > > This looks like a job for table-gen?
> > > Also, please, don't add more getProcFamily calls, use sub-target features.
> > For Cyclone, only subset of 6 instruction fusion cases are applicable, but for Vulcan, additional instructions are applicable, which may not be applicable for Cyclone. 
> > So, to generalize this under one 'Subtarget Feature', getProcFamily call seems unavoidable. Please suggest.
> > 
> > Or, Is a new subtarget feature, such as 'FeatureMacroOpFusionVulcanSubset' a better option? 
> > 
> > Also, I am not sure about the table-gen option and how it can be done there. 
> This is not a Cyclone vs Vulcan, but some things are more profitable than others, and it's possible, as you said, that this is the case for other cores, including Cyclone.
> A new target feature is needed, but one with "vulcan" in its name, because that would defeat the purpose. We are getting rid of things like that, ex. "isLikeA9" because it's a trap.
> The table-gen option would be to add a property to those instructions and use a check on that property here. I'll pass on the benefits of that apporach vs. this (other people can chime in), but this is orthogonal to the target feature discussion.
> Bottom line is: we don't want *more* CPU checks.
The approach of adding a new sub-feature for Macro-op fusion, by categorizing the instructions (my presumption) doesn't seem a good option. It will end up adding too many subfeature such as FeatureMacroOpFusionArith/FeatureMacroOpFusionLogical. Please correct me.

I approached the table-gen option of adding instruction property, similar to adding CheapAsAMov property.  But, in MCID Flags, there are already 32 flags, 'new flag MacroOpFusable' becomes the 33rd flag.  As there might be future flags as well, which someone might add, so we should use it as a 64-bit. 

I am thinking of submitting a 'new diff' on this review by just enabling 'FeatureMacroOpFusion' (AArch64.td file modification) for Vulcan and let only ADDS, SUBS, ANDS get fused (default Subtarget feature behavior) and work on table-gen part for complete solution. Please suggest.


More information about the llvm-commits mailing list