[LLVMdev] running clang format on the Mips target

Tobias Grosser tobias at grosser.es
Thu Jan 9 02:53:01 PST 2014

Manuel, Daniel,

I forgot to CC you in this mail. The thread here may be interesting to 
you, also in the light of the last discussion we had.


On 12/21/2013 12:00 AM, Tobias Grosser wrote:
> On 12/20/2013 11:18 PM, Rafael EspĂ­ndola wrote:
>> On 20 December 2013 15:52, reed kotler <rkotler at mips.com> wrote:
>>> We are considering running clang format on the whole Mips target.
>>> Is there any rule against this?
>> I don't think there is a rule, but even simpler things like "remove
>> all trailing spaces" were not common in the past
>>> Is there any good argument against doing this even if there is no rule
>>> against it?
>> It think the argument was that it makes history harder to follow. A
>> git blame lands you on the reformatting patch and you have to manually
>> skip them.
>> I don't personally consider that a strong argument and I think polly
>> did just that (run clang-format on everything), so it might be OK
>> these days.
> Unfortunately for Polly it was not as clean as we started using
> clang-format early, so we had to format piece by piece the sections that
> clang-format could already handle.
> However, we now have an automatic clang-format buildbot so formatting
> became (in some way) a 'solved problem'.
> One benefit of fully formatted source code is that there is no need for
> any new patches to include 'formatting fixes', which previously
> sometimes obfuscated submitted patches and commits. In fact, patch
> reviews are now free of formatting discussions. If the patch passes
> make polly-check-format, it is ready to be discussed. (If it does not,
> make polly-update-format needs to be run). Also, having a single
> formatting commit to skip might arguably be easier, than to have a mixed
> history of formatting and patches.
> One reason that may hold us back from formatting all LLVM code is the
> risk of clang-format changing its formatting behavior. The only thing
> worse than formatting all code is formatting all code twice. ;)
>  From my experience with Polly, clang-format's formatting has been
> largely stable the last months. Changes in its formatting behavior have
> normally been fixed quickly. So it may make sense to format more code.
> I would still be afraid of formatting all LLVM, but maybe a backend is
> a reasonable sized chunk.
> Maybe Manual and Daniel have some experience in formatting a larger set
> of files.

More information about the llvm-dev mailing list