Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Provide a way to add spaces inside an initalizer list when formatting #34646

Open
hughbe opened this issue Nov 14, 2017 · 1 comment
Open

Provide a way to add spaces inside an initalizer list when formatting #34646

hughbe opened this issue Nov 14, 2017 · 1 comment
Labels
bugzilla Issues migrated from bugzilla clang-format

Comments

@hughbe
Copy link

hughbe commented Nov 14, 2017

Bugzilla Link 35298
Version 5.0
OS MacOS X

Extended Description

E.g.

static CapClass vtable = { CustomLineCapTypeAdjustableArrow,
gdip_adjust_arrowcap_setup,
gdip_adjust_arrowcap_clone_cap,
gdip_adjust_arrowcap_destroy,
gdip_adjust_arrowcap_draw };

Formatting this code with clang-format removes the spaces inside the initializer list:

static CapClass vtable = {CustomLineCapTypeAdjustableArrow,
gdip_adjust_arrowcap_setup,
gdip_adjust_arrowcap_clone_cap,
gdip_adjust_arrowcap_destroy,
gdip_adjust_arrowcap_draw};

Please provide a way (e.g. something like SpacesInSquareBrackets) to provide the functionality to add spaces inside an initializer list.
@llvmbot
Copy link
Member

llvmbot commented Nov 14, 2017

Have you tried setting Cpp11BracedListStyle to false?

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
atrosinenko added a commit that referenced this issue Nov 6, 2024
@atrosinenko
[AArch64][PAC] Eliminate excessive MOVs when computing blend
54cb6c8 
As function calls do not generally preserve X16 and X17, it is beneficial
to allow AddrDisc operand of B(L)RA instruction to reside in these
registers and make use of this condition when computing the discriminator.

This can save up to two MOVs in cases such as loading a (signed) virtual
function pointer via a (signed) pointer to vtable, for example

    ldr   x9, [x16]
    mov   x8, x16
    mov   x17, x8
    movk  x17, #34646, lsl #48
    blraa x9, x17

can be simplified to

    ldr   x8, [x16]
    movk  x16, #34646, lsl #48
    blraa x8, x16
atrosinenko added a commit that referenced this issue Nov 11, 2024
@atrosinenko
[AArch64][PAC] Eliminate excessive MOVs when computing blend
c4fa68c 
As function calls do not generally preserve X16 and X17, it is beneficial
to allow AddrDisc operand of B(L)RA instruction to reside in these
registers and make use of this condition when computing the discriminator.

This can save up to two MOVs in cases such as loading a (signed) virtual
function pointer via a (signed) pointer to vtable, for example

    ldr   x9, [x16]
    mov   x8, x16
    mov   x17, x8
    movk  x17, #34646, lsl #48
    blraa x9, x17

can be simplified to

    ldr   x8, [x16]
    movk  x16, #34646, lsl #48
    blraa x8, x16
atrosinenko added a commit that referenced this issue Nov 12, 2024
@atrosinenko
[AArch64][PAC] Eliminate excessive MOVs when computing blend
9cf30ea 
As function calls do not generally preserve X16 and X17, it is beneficial
to allow AddrDisc operand of B(L)RA instruction to reside in these
registers and make use of this condition when computing the discriminator.

This can save up to two MOVs in cases such as loading a (signed) virtual
function pointer via a (signed) pointer to vtable, for example

    ldr   x9, [x16]
    mov   x8, x16
    mov   x17, x8
    movk  x17, #34646, lsl #48
    blraa x9, x17

can be simplified to

    ldr   x8, [x16]
    movk  x16, #34646, lsl #48
    blraa x8, x16
atrosinenko added a commit that referenced this issue Nov 12, 2024
@atrosinenko
[AArch64][PAC] Eliminate excessive MOVs when computing blend
070797b 
As function calls do not generally preserve X16 and X17, it is beneficial
to allow AddrDisc operand of B(L)RA instruction to reside in these
registers and make use of this condition when computing the discriminator.

This can save up to two MOVs in cases such as loading a (signed) virtual
function pointer via a (signed) pointer to vtable, for example

    ldr   x9, [x16]
    mov   x8, x16
    mov   x17, x8
    movk  x17, #34646, lsl #48
    blraa x9, x17

can be simplified to

    ldr   x8, [x16]
    movk  x16, #34646, lsl #48
    blraa x8, x16
atrosinenko added a commit that referenced this issue Nov 26, 2024
@atrosinenko
[AArch64][PAC] Eliminate excessive MOVs when computing blend
17acf80 
As function calls do not generally preserve X16 and X17, it is beneficial
to allow AddrDisc operand of B(L)RA instruction to reside in these
registers and make use of this condition when computing the discriminator.

This can save up to two MOVs in cases such as loading a (signed) virtual
function pointer via a (signed) pointer to vtable, for example

    ldr   x9, [x16]
    mov   x8, x16
    mov   x17, x8
    movk  x17, #34646, lsl #48
    blraa x9, x17

can be simplified to

    ldr   x8, [x16]
    movk  x16, #34646, lsl #48
    blraa x8, x16
atrosinenko added a commit that referenced this issue Nov 27, 2024
@atrosinenko
[AArch64][PAC] Eliminate excessive MOVs when computing blend (#115185)
1fccba5 
As function calls do not generally preserve X16 and X17, it is beneficial
to allow AddrDisc operand of BLRA instruction to reside in these
registers and make use of this condition when computing the
discriminator.

This can save up to two MOVs in cases such as loading a (signed) virtual
function pointer via a (signed) pointer to vtable, for example

    ldr   x9, [x16]
    mov   x8, x16
    mov   x17, x8
    movk  x17, #34646, lsl #48
    blraa x9, x17

can be simplified to

    ldr   x8, [x16]
    movk  x16, #34646, lsl #48
    blraa x8, x16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla clang-format
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hughbe @llvmbot