[PATCH] [arm] Implement ARM .arch directive.

Richard Barton richard.barton at arm.com
Wed Nov 13 10:22:16 PST 2013

  Hi Logan

  Sorry for the delayed response.

  My worry was that we set up the ARMSubtarget from the commandline with a list of enabled features. The ARMAsmPrinter will emit build attributes based on these features. It then calls the TargetAsmStreamer which may override these attributes with a different set of defaults. So we are setting defaults in both the ARMSubtarget and the ARMTargetStreamers. My instinct was that rather than maintaining its own list of Architecture -> build attributes mapping, it should simply map to the relevant architecture in the ARMSubtarget, The build attributes would then be generated by the existing code path in ARMAsmPrinter.

  I suppose that what we are trying to achieve here is to emulate some gcc behaviour, so the attributes that we override should exactly match the attributes that gcc sets, and not the set of attributes that llvm sets for a particular architecture. Given this, I agree that a separate list is appropriate.

  I think that this patch is fine to go in. I'll admit that I haven't checked that it matches the gcc behaviour, but it looks sensible.

  It might be beyond the scope of what you are trying to achieve.

  I'm curious to know what would happen if we invoke the assembler with -march armv7a and pass it an assembly file with an arch directive like in your example: .arch armv5te. Which set of defaults would win? The commandline ones or the assembly file ones?

  Also does gcc set any build attributes to 0 for the .arch directives? e.g. if I tried to assemble a file with -mattr=+hwdiv-arm on the commandline and an arch directive in the file, would the Tag_DIV_use attribute be generated in the output object?




More information about the llvm-commits mailing list