[Bug middle-end/104763] [12 Regression] Generate wrong assembly code

[570070308 at qq dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104763

--- Comment #8 from 。 <570070308 at qq dot com> ---
(In reply to Richard Biener from comment #7)
> Note that the case of an endless loop is somewhat special since the store
> is dead there since there is no way to reach a load from that point with
> C standard methods.  So one could also argue the optimization is valid
> and this bug is invalid.
> 
> How did you end up with this case?

I agree with this bug is invaild.
I do something on memory 0xb8000, this is because the 0xb8000 is the video
memory, and can display on screen.
However gcc don't know it, and I think it doesn't need to know it. Gcc can
simply think that all the writing/reading on memory is useless, unless the
writing/reading on memory will affect subsequent function calls or the function
return. This way gcc can better optimize the code.
According to this, the while(1){} will never return or call a function, so gcc
can think that all the writing/reading on 0xb8000 before while(1){} is useless.
A way to tell gcc that writing/reading on 0xb8000 will make an impact is to
change `*i` to `*(volatile size_t *)i`, and it really work.

So I think:
test.c:
```
void move_up()
{
    for ( size_t* i=(size_t *)(0xb8000+160*24); ; )
    {
        *i=0x0700070007000700;
        if ( i == (size_t *)(0xb8000+160*24)+2 )
        {
            break;
        }
        ++i;
    }
    while (1){}
}
```
compile to
```
move_up:
    jmp move_up
```
and test.c:
```
void move_up()
{
    for ( size_t* i=(size_t *)(0xb8000+160*24); ; )
    {
        *(volatile size_t *)i=0x0700070007000700;
        if ( i == (size_t *)(0xb8000+160*24)+2 )
        {
            break;
        }
        ++i;
    }
    while (1){}
}
```
compile to:
```
move_up:
    movabsq $504410854964332288, %rax
    movq    %rax, 757504
    movq    %rax, 757512
    movq    %rax, 757520
.L2:
    jmp .L2
```
is the best.