Logic OR reset and clear?
Your instincts for the conditional if are correct. Some synthesis tools may understand what you are trying to do, but many will not as what you have written is not an established pattern so the tools may not infer what you want in the way you want it.
The standard (if there is such a thing)/ accepted way to write what you are trying to achieve is like this:
process(clk, reset)
begin
  if reset = '1' then  -- async reset
    -- your code here
  elsif Rising_edge(clk) then
    if sync_clr = '1' then  -- sync clear
      -- your code here
    end if;
  end if;
end process;

I note that your reset is active low which tends to be frowned upon within the FPGA (more to do with code readability than actual architectural issues).
But wait! Why does any of this actually matter?
This comes down  to the individual architecture of the FPGA you are using. Below is a snippet of the block diagram for a Cyclone V Adaptive Logic Module.

Looking at the registers you can see that they only have a single control - CLR. At the top of the diagram you can see the signals aclr[1:0] coming into the ALM. When you infer an async reset, this is what is set. Note that this ALM has 4 registers but only 2 reset signals that are shared by the pairs. This has an implication for how many ALMs are used.
You can also see a synchronous clear signal (sclr) and a synchronous load signal (syncload) coming into the ALM. These are shared by all 4 registers. These circuits will be used if inferred in code. The diagram is detailed enough to be able to understand how the signals work.
sclr is intended to be active high. It is inverted and ANDed with data that feeds the D input of the registers. That means when high, 0 is fed to the D input and Q updates to 0 on the next clock cycle.
syncload drives a multiplexor which selects either the outputs from the LUTs or datae0 which originates outside the ALM.
Note how there is no asynchronous set. If you wrote this, then the tools would be unable to match this to the device architecture and instead implement using LUTs. This is the same for every control that is not part of the devices architecture.
Xilinx have a white paper that explains this in a lot more detail:
https://www.xilinx.com/support/documentation/white_papers/wp275.pdf