public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/105032] Compiling inline ASM x86 causing GCC stuck in an endless loop with 100% CPU usage Date: Wed, 23 Mar 2022 13:50:18 +0000 [thread overview] Message-ID: <bug-105032-4-tQaL0Qht0a@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-105032-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105032 --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Consider e.g. void bar (int *); int foo (int *a, int *b, int *c, int *d) { for (int i = 0; i < 1024; i++) a[i] = a[i] * b[i] + (c[i] - d[i]); bar (a); return 42; } with -m32 -O3 -mavx -mstackrealign. It needs to dynamically realign the stack because user asked for it (so that it can use 256-bit aligned stack slots and callers don't guarantee that alignment), so it needs a frame pointer (%ebp), stack pointer (%esp) and DRAP (%ecx in this case). Especially if you e.g. also use VLAs or alloca in the function. %ebp based addressing is for the automatic vars in the function in its stack frame, stack pointer can be variable offset from it used for outgoing arguments to function calls and push/pop or for alloca/VLAs and DRAP is used to access function arguments which aren't at fixed offset from the frame pointer either. Anyway, with the "b" etc. constraints (which is a good idea to use on x86 when it has single register constraints for those but can't be used on other arches which do not have such constraints) you just trigger slightly different path in the RA, but the problem remains roughly the same, you force use of 6 registers as input plus one memory address and esp is a stack pointer and ebp could be a frame pointer and it is a question if you don't need another register for the address of the memory input. A way to free one input would be to store 2 arguments into an array and use the whole array as one memory input and only inside of the inline asm load it into the right registers.
next prev parent reply other threads:[~2022-03-23 13:50 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-23 3:46 [Bug c/105032] New: " ammarfaizi2 at gmail dot com 2022-03-23 3:52 ` [Bug middle-end/105032] " pinskia at gcc dot gnu.org 2022-03-23 4:05 ` crazylht at gmail dot com 2022-03-23 9:24 ` jakub at gcc dot gnu.org 2022-03-23 9:28 ` jakub at gcc dot gnu.org 2022-03-23 13:22 ` ammarfaizi2 at gmail dot com 2022-03-23 13:27 ` ammarfaizi2 at gmail dot com 2022-03-23 13:50 ` jakub at gcc dot gnu.org [this message] 2022-03-23 19:24 ` hjl.tools at gmail dot com 2022-03-29 12:49 ` vmakarov at gcc dot gnu.org 2022-03-30 17:02 ` vmakarov at gcc dot gnu.org 2022-03-30 17:10 ` cvs-commit at gcc dot gnu.org 2022-03-30 17:12 ` vmakarov at gcc dot gnu.org 2022-04-01 14:21 ` cvs-commit at gcc dot gnu.org 2022-07-28 18:43 ` hjl.tools at gmail dot com 2022-08-02 6:18 ` andrey.vihrov at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-105032-4-tQaL0Qht0a@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).